I imagine this is probably a troll, but just in case:
The language chosen would have very, very little effect on this. This is a problem with the overall design of the app.
Rust, like Python, Java, Perl, PHP, VBScript, JavaScript, and most other languages, doesn't lend itself to one very specific type of bug called a buffer overflow. That specific issue is mostly just seen in C. Rust is like most languages in that buffer overflow isn't the bug you have to worry about in Rust (or in Perl, PHP, Python, Java, etc.)
What's different about Rust is a very clever marketing thing they did. They took the fact that most languages, including Rust, don't have buffer overflows and hyped it to Trumpian proportions. In marketing material that would make PT Barnum blush, they exclaimed "Rust is secure because it doesn't have buffer overflows! Write all your software in Rust and you'll never have another bug!" Understand this is analogous to saying "spiders are venomous, don't use spiders. Tigers have no venom! If you use tigers, you never have to worry about venom at all. Buy some tigers from us today so you can be safe!"
The problem then is that newbies who don't understand much about programming *think* they're safe because they're using tigers. No need to be careful with tigers because they aren't venomous. Er, I mean no need to be careful when you're using Rust because it doesn't have buffer overflows. That makes it slightly more dangerous, since a lot of people aren't being as careful as they should, thinking Rust is somehow magic.
I maintain a database of every CVE (security bug) ever reported. Well under 1% of them are buffer overflows, so it's a tiny percentage of problems that Rust protects against.
> do not get angry at HLS for asking it but at the judge for giving it, if you think they should not have done that.
We don't know why they're asking, or what basis (evidence) they have to support the subpoena, but let's assume for a moment that there is a bad subpoena, that the subpoena shouldn't have been done. If so, I would definitely blame the people who decided to get a bad subpoena that they shouldn't have gotten. "The judge let us get away it" isn't an excuse for doing bad things.
If a subpoena is not only bad but also illegal, the judge would ALSO be at fault for allowing an illegal subpoena. (Remember judges rule on what's legal, not on what they think is good).
In fact I would go so far as to say a free country *requires* we hold ourselves to a higher standard than "it's fine to do anything, so long as a judge doesn't rule it illegal". If we as a society decide we'll all do whatever nasty things as long as the law lets us get away with it, then we'd need laws against everything that might be a problem. If the only limits we put on our behavior is the law, pretty soon we need laws to stop all kinds of things, totalitarianism is required. If instead we live based on trying to do the right thing, to be considerate of others and avoid causing problems for other people (law or not), then we don't need so many laws. We can have a functioning society that is much more free of we each use our freedom in ways that are respectful and considerate of others, we don't need laws telling us exactly what we can and can't do.
> I thought it was a judge who did the subpoena and not HLS?
In this instance the agency can issue a subpoena. If someone doesn't comply with the subpoena, they can ask a court to enforce it.
According to all the articles in 2016, Tesla plans to build 500,000 Model 3 in 2018. They issued and sold an additional $2 billion in stock based on this plan.
Somehow Tesla's actual performance never resembles the plans they announce.
The EEO-1 Report listing racial breakdown of current employees of required under OEC regulations promulgated under Section VII of the Civil Rights Act of 1964.
As far as any requirement to publicly list job openings - citation sorely needed, because it's common knowledge, supported by many surveys, that the majority of openings are never listed.
Between 70%-85% of job openings in private sector are never listed at all. Rather, when an opening happens, someone at the company knows somebody who would be a fit, typically someone they used to work with. That's how MOST jobs are filled.
My first salaried job in a big company was like that. I had worked with a guy doing "side gigs" and he knew I was passively looking for a new job - I would be interested if the right position came along. When the right position opened up in the agency he worked for, he called me, and recommend me to the hiring manager. Policy required interviewing three people, but the job was mine because he recommended me bases on knowing I had acted professionally and done a good job before.
From that company, I have a few contacts. My old boss was good, so I've told her to let me know if she's ever in the market for a new job, and she's told me the same. Her and her boss have told me more than once they'll have a spot for me if I ever want to come back.
There are a few other people from the job who I've communicated with the same way - if either of us ever needs a job, or has the right position open, we'll contact each other. We wouldn't do that with unprofessional people who ghosted.
So it's not so much that a stranger will call around (though that happens to), but rather people WON'T call the unprofessional people, they WILL call the people they've worked with who were highly professional.
My last boss is now a high-ranking VP for a major bank. He's hired me before, and I think I did a good job for him, so whenever I need a new job I can always get a job at his bank. I expect he WILL call people he still knows at my current company, confirming that I haven't become an unprofessional asshole since he and I last worked together.
I had envisioned something a tad different when I read your earlier post.
That's fairly similar to part of what I did on the very cool backup service I used to sell. Except I used LVM snapshots rather than ZFS, which gave us the flexibility to do some other really cool stuff.
Sometimes the integration of ZFS is handy, sometimes it's a major limitation. It's a lot more flexible to use a file system as a file system, a volume manager as a volume manager, and RAID for RAID. ZFS tries to be all three, creating coupling that is entirely unnecessary (but convenient if your needs are simple).
I'm going to guess that what is your pocket is a pocket-sized tablet. So, a phone. Except it can't make calls. Also, the OS is 20 GB, leaving 4 GB for the user. Oh, and it's based on Windows, so the battery runs out in three hours.
Other than those minor nitpicks, it's almost as good as a smartphone. Just a lot more expensive.
Ransomware typically wipes any network drives using the SMB protocol, as Samba does, if the infected machine has access to the share. That can be made secure by the backup backup pulling files that are shared by machine to be backed up. So the reverse of the typical model.
I also see that for the past SIX YEARS it's been flagged as needing references. Each page has only a single reference, and the Osu page consists of a single sentence.
If you think these topics are important, important enough that they've been written about, spend 10 minutes on Google to find a few articles and add them as references. It's really not hard.
If you actually take the 20 minutes to READ the articles, you can then type some information from those sources into the Wikipedia article, so it'll be an article instead of a sentence.
You've had six years notice, how long do you need in order to spend a few minutes adding a couple links?
This article has several links to Poettering responding to security bugs, and what he what he's (not) going to do to fix problems, or note any fixes in the changelings or commit messages. This is why he won the Pwnie award for lamest vendor response to security issues.
That's where I would go looking. Lennart Poettering has been pretty clear that his perspective is that it's not his job, or the job of the systemd developers, to write secure, robust code. It's the job of the annoying security people to point out the security issues and then convince him that the problem is so bad it absolutely must be fixed - even though that takes up time that could instead be used to make systemd bigger and more comprehensive.
The last time I saw a similarly bad attitude about security was WordPress about 12 years ago. The leadership at WordPress got a better attitude after the media reported widespread exploits of exactly the kinds of exposures I had warned them about a couple years before.
It's hard to believe Google's engineers don't include a significant percentage of gamers, but this idea seems to suggest that may be the case. There is little chance that gamers will get what they want from streaming.
Games like the Sims, Angry Birds, and Candy Crush sure, you could stream The Sims.
Although Hollywood movies look great at 24fps, and HDTV is fine running at 30fps, gamers will want 120fps, minimum 60fps.
Several times I've seen the backup server ran out of space. The ssh key was changed. The list of directories to backup or not backup wasn't up to date. Those are a few things that have broken it after it was setup and running.
All of these can be detected by occasionally doing a test restore, perhaps to a VM, and checking that the important files are there and important functionality works.
> apps will need to be reinstalled but at least on Linux that's fairly easy.
Re-installing the software is REALLY easy if your data includes the output of rpm -qa.
Also sometimes very handy when things go wrong - cat/proc/mdstat, pvdisplay, lvmbackup, and gdisk -l
I'm recovering an old customer's data right now. He no longer has backups with me and someone built a new, wmpty raid on his drives, making it "impossible" to recover his data. However, the old copies of mdstat and the partition layout were still hanging around from when he uses to have the backup service I used to sell. That info allowed me to reconstruct his storage from a seemingly destroyed state.
That's a very good question. You can use diff to see what the differences are between different backups. That normally makes it pretty obvious. You pretty much know which files were supposed to change and which weren't. This can even give you good hints as to HOW you got infected.
There are even faster ways to tell because rootkits tend to re-send the same components. I can normally see a rootkit on a Linux system in seconds, without even actively looking for it. I'm not going to post the trick here because I don't want the rootkit authors to fix it.
Thank you for post. You've done great job listing things that fool smart, conscientious people into thinking they have a backup. That's why I said a "proper backup", proper being an important word. Those things all LOOK a lot like proper backup, don't they? And yet people who do those things end up asking me to try forensic techniques to recover their data. You seem like you know a few things, so I don't need to tell you exactly how you should do a backup, but let me point out a few common pitfalls to avoid:
> Windows sets you up with OneDrive and points all of your storage stuff to OneDrive. The result is that all your files are backed up.
The result of the default setup is that all of your infected files are stored on One Drive. This doesn't help. Your files are still infected. There is no backup copy, only the infected copy, so they are not backed up. It doesn't do you any good to have the infected files there rather than here.
So here's our first file of proper backup: backups must store multiple versions going back in time, with old versions immutable.
Recently, Microsoft has offered an option to store old versions if you pay a subscription to Office. If you're paying for it already, you may want to look into that option.
> Windows Backup and Restore or Apple Time Machine which does pretty much the same thing.
For those unfamiliar, Time Machine uses a USB drive connected to your computer, or a network drive to store old versions. The interface is really nice and it's awesome when you realize you screwed up and deleted or overwrote an important file. It's the ultimate undo. When you have a fire, a burglary, a flood, or a ransomware infection, that'll take both your computer itself and the USB drive. So this isn't proper backup - you're not protected a good against most types of catastrophic loss. It's a really cool extension of ctrl-z, though, to get back that file you just messed up.
This illustrates proper backups are off site. I used to do backups for web sites. I pointed out that just in Texas alone, every year for the last four years there had been major disaster at a public datacenter. Anyone who had a server at one of these data centers and had their "backup" in the same datacenter lost everything. In one instance, I had to get creative in retrieving some customers' data from a datacenter after the company operating it failed to pay their lease and took off into the night.
Backups must be in a separate physical location - a fire, flood, or burglary will take or destroy everything in your office.
I mentioned before backups must be tested regularly. Backups that haven't been recently tested have a failure rate of about 50%, in my experience.
They also need to be automated, because most people only do manual systems properly for a little while, then try start slacking off and eventually "forget" to run a backup for six months.
Ransomware reminds us of another requirement - the system being backed up (which may get ransomware) can not have the ability to delete or modify the backups. Sending backups to a network drive just means the ransomware or disgruntled employee will destroy two copies of the data.
> That said, to be honest, I have absolutely no idea how to maintain good backups of my Linux systems.
After I sold one of my companies, I spent a year and half designing and building a very good backup for Linux systems. The new company backup up the web servers for hundreds of web sites. The backups were kept off site, they kept several versions, the protected system had no way to remove the backups, they were fully automated, and you could easily restore any files at any time to test it. Add a bonus, you could click a button and BOOT the backup - they were stored as virtual machines.
It's too bad my skills at running a business aren't nearly as good as my engineering skills. I was like Wozniak without Steve Jobs - I built something really cool, something really useful, but making a successful, stable company from it wasn't my forte. If you actually have a ton of Linux systems, and if you care about any them, maybe we should talk. I still have some pretty awesome backup software for Linux.
One technique for data sterilization is to convert to a different format. For example, converting a Word document to WordPerfect will make sure there are no macros, I believe. Then convert back. Even better, convert to plain text if possible, and leave it as plain text. JPG to bump, etc.
Absolutely you're right the best way to handle a rootkit is restore from a known-good backup. Just like you practiced, last month when you tested it when found and fixed the problem with backup system.
Unfortunately, 90% of people don't have a proper backup system. Probably over half of systems that are being "backed up" can't actually be restored because the backup media went bad a year ago or whatever.
For the people who don't have a solid backup:
> some IT professional who sells himself to a client by claiming he can remove this and leave the user's precious data intact?
What you definitely don't do is try to salvage the operating system and programs. Just re-install those. It was time to upgrade anyway. DATA *can* be painstakingly recovered. It's a heck of a lot easier if your data isn't mixed with code - no MS Office macros, etc. If you keep your data separate from executable code, it absolutely can be recovered, though it's very easy to slip up and let a potentially infected file through.
It sounds like this is an identifier rather than an encryption key, but let's suppose we're talking about keys, and specifically private keys.
Yes, it's more secure to generate a private key on the device, so insider threats don't know the key. However, that makes it MORE likely to have duplicates, not less likely. Generating them externally, you can easily ensure you don't get repeats, or more easily, control the likelihood of repeats with a good random source.
If the device generates it's own key, the default is that two cameras with the same electronics will generate the same key. You have to put in significant work to come up with a pseudo random number from determinate electronics. Unless the device publishes something about the key, you can't be sure there are no duplicates.
Slashdot Mirror
Siegfried & Roy might have thought that, until 2003.
I imagine this is probably a troll, but just in case:
The language chosen would have very, very little effect on this. This is a problem with the overall design of the app.
Rust, like Python, Java, Perl, PHP, VBScript, JavaScript, and most other languages, doesn't lend itself to one very specific type of bug called a buffer overflow. That specific issue is mostly just seen in C. Rust is like most languages in that buffer overflow isn't the bug you have to worry about in Rust (or in Perl, PHP, Python, Java, etc.)
What's different about Rust is a very clever marketing thing they did. They took the fact that most languages, including Rust, don't have buffer overflows and hyped it to Trumpian proportions. In marketing material that would make PT Barnum blush, they exclaimed "Rust is secure because it doesn't have buffer overflows! Write all your software in Rust and you'll never have another bug!" Understand this is analogous to saying "spiders are venomous, don't use spiders. Tigers have no venom! If you use tigers, you never have to worry about venom at all. Buy some tigers from us today so you can be safe!"
The problem then is that newbies who don't understand much about programming *think* they're safe because they're using tigers. No need to be careful with tigers because they aren't venomous. Er, I mean no need to be careful when you're using Rust because it doesn't have buffer overflows. That makes it slightly more dangerous, since a lot of people aren't being as careful as they should, thinking Rust is somehow magic.
I maintain a database of every CVE (security bug) ever reported. Well under 1% of them are buffer overflows, so it's a tiny percentage of problems that Rust protects against.
Your post was interesting, thanks.
> do not get angry at HLS for asking it but at the judge for giving it, if you think they should not have done that.
We don't know why they're asking, or what basis (evidence) they have to support the subpoena, but let's assume for a moment that there is a bad subpoena, that the subpoena shouldn't have been done. If so, I would definitely blame the people who decided to get a bad subpoena that they shouldn't have gotten. "The judge let us get away it" isn't an excuse for doing bad things.
If a subpoena is not only bad but also illegal, the judge would ALSO be at fault for allowing an illegal subpoena. (Remember judges rule on what's legal, not on what they think is good).
In fact I would go so far as to say a free country *requires* we hold ourselves to a higher standard than "it's fine to do anything, so long as a judge doesn't rule it illegal". If we as a society decide we'll all do whatever nasty things as long as the law lets us get away with it, then we'd need laws against everything that might be a problem. If the only limits we put on our behavior is the law, pretty soon we need laws to stop all kinds of things, totalitarianism is required. If instead we live based on trying to do the right thing, to be considerate of others and avoid causing problems for other people (law or not), then we don't need so many laws. We can have a functioning society that is much more free of we each use our freedom in ways that are respectful and considerate of others, we don't need laws telling us exactly what we can and can't do.
> I thought it was a judge who did the subpoena and not HLS?
In this instance the agency can issue a subpoena. If someone doesn't comply with the subpoena, they can ask a court to enforce it.
According to all the articles in 2016, Tesla plans to build 500,000 Model 3 in 2018. They issued and sold an additional $2 billion in stock based on this plan.
Somehow Tesla's actual performance never resembles the plans they announce.
Here are quite a few for you to choose from.
https://www.google.com/search?...
The EEO-1 Report listing racial breakdown of current employees of required under OEC regulations promulgated under Section VII of the Civil Rights Act of 1964.
As far as any requirement to publicly list job openings - citation sorely needed, because it's common knowledge, supported by many surveys, that the majority of openings are never listed.
Between 70%-85% of job openings in private sector are never listed at all. Rather, when an opening happens, someone at the company knows somebody who would be a fit, typically someone they used to work with. That's how MOST jobs are filled.
My first salaried job in a big company was like that. I had worked with a guy doing "side gigs" and he knew I was passively looking for a new job - I would be interested if the right position came along. When the right position opened up in the agency he worked for, he called me, and recommend me to the hiring manager. Policy required interviewing three people, but the job was mine because he recommended me bases on knowing I had acted professionally and done a good job before.
From that company, I have a few contacts. My old boss was good, so I've told her to let me know if she's ever in the market for a new job, and she's told me the same. Her and her boss have told me more than once they'll have a spot for me if I ever want to come back.
There are a few other people from the job who I've communicated with the same way - if either of us ever needs a job, or has the right position open, we'll contact each other. We wouldn't do that with unprofessional people who ghosted.
So it's not so much that a stranger will call around (though that happens to), but rather people WON'T call the unprofessional people, they WILL call the people they've worked with who were highly professional.
My last boss is now a high-ranking VP for a major bank. He's hired me before, and I think I did a good job for him, so whenever I need a new job I can always get a job at his bank. I expect he WILL call people he still knows at my current company, confirming that I haven't become an unprofessional asshole since he and I last worked together.
I had envisioned something a tad different when I read your earlier post.
That's fairly similar to part of what I did on the very cool backup service I used to sell. Except I used LVM snapshots rather than ZFS, which gave us the flexibility to do some other really cool stuff.
Sometimes the integration of ZFS is handy, sometimes it's a major limitation. It's a lot more flexible to use a file system as a file system, a volume manager as a volume manager, and RAID for RAID. ZFS tries to be all three, creating coupling that is entirely unnecessary (but convenient if your needs are simple).
> Actually my phone can make calls because I have a nice iPhone
Ah, so it can make calls. Unless your thumb is in a comfortable position. That's okay, though, it's innovative - it has rounded corners.
I'm going to guess that what is your pocket is a pocket-sized tablet. So, a phone. Except it can't make calls. Also, the OS is 20 GB, leaving 4 GB for the user. Oh, and it's based on Windows, so the battery runs out in three hours.
Other than those minor nitpicks, it's almost as good as a smartphone. Just a lot more expensive.
Ransomware typically wipes any network drives using the SMB protocol, as Samba does, if the infected machine has access to the share. That can be made secure by the backup backup pulling files that are shared by machine to be backed up. So the reverse of the typical model.
> Wikipedia is it considers the cult games Osu! and Kid Pix as not notable and sent its deletionists
I see that there are Wikipedia articles for both. The Kid Pix article has been up for at least 13 years.
https://en.m.wikipedia.org/wik...
https://en.m.wikipedia.org/wik...!
I also see that for the past SIX YEARS it's been flagged as needing references. Each page has only a single reference, and the Osu page consists of a single sentence.
If you think these topics are important, important enough that they've been written about, spend 10 minutes on Google to find a few articles and add them as references. It's really not hard.
If you actually take the 20 minutes to READ the articles, you can then type some information from those sources into the Wikipedia article, so it'll be an article instead of a sentence.
You've had six years notice, how long do you need in order to spend a few minutes adding a couple links?
This article has several links to Poettering responding to security bugs, and what he what he's (not) going to do to fix problems, or note any fixes in the changelings or commit messages. This is why he won the Pwnie award for lamest vendor response to security issues.
https://www.theregister.co.uk/...
> now... let me see the quality of systemd code
That's where I would go looking. Lennart Poettering has been pretty clear that his perspective is that it's not his job, or the job of the systemd developers, to write secure, robust code. It's the job of the annoying security people to point out the security issues and then convince him that the problem is so bad it absolutely must be fixed - even though that takes up time that could instead be used to make systemd bigger and more comprehensive.
The last time I saw a similarly bad attitude about security was WordPress about 12 years ago. The leadership at WordPress got a better attitude after the media reported widespread exploits of exactly the kinds of exposures I had warned them about a couple years before.
It's hard to believe Google's engineers don't include a significant percentage of gamers, but this idea seems to suggest that may be the case. There is little chance that gamers will get what they want from streaming.
Games like the Sims, Angry Birds, and Candy Crush sure, you could stream The Sims.
Although Hollywood movies look great at 24fps, and HDTV is fine running at 30fps, gamers will want 120fps, minimum 60fps.
Several times I've seen the backup server ran out of space. The ssh key was changed. The list of directories to backup or not backup wasn't up to date. Those are a few things that have broken it after it was setup and running.
All of these can be detected by occasionally doing a test restore, perhaps to a VM, and checking that the important files are there and important functionality works.
> apps will need to be reinstalled but at least on Linux that's fairly easy.
Re-installing the software is REALLY easy if your data includes the output of rpm -qa.
Also sometimes very handy when things go wrong - /proc/mdstat, pvdisplay, lvmbackup, and gdisk -l
cat
I'm recovering an old customer's data right now. He no longer has backups with me and someone built a new, wmpty raid on his drives, making it "impossible" to recover his data. However, the old copies of mdstat and the partition layout were still hanging around from when he uses to have the backup service I used to sell. That info allowed me to reconstruct his storage from a seemingly destroyed state.
That's a very good question. You can use diff to see what the differences are between different backups. That normally makes it pretty obvious. You pretty much know which files were supposed to change and which weren't. This can even give you good hints as to HOW you got infected.
There are even faster ways to tell because rootkits tend to re-send the same components. I can normally see a rootkit on a Linux system in seconds, without even actively looking for it. I'm not going to post the trick here because I don't want the rootkit authors to fix it.
Thank you for post. You've done great job listing things that fool smart, conscientious people into thinking they have a backup. That's why I said a "proper backup", proper being an important word. Those things all LOOK a lot like proper backup, don't they? And yet people who do those things end up asking me to try forensic techniques to recover their data. You seem like you know a few things, so I don't need to tell you exactly how you should do a backup, but let me point out a few common pitfalls to avoid:
> Windows sets you up with OneDrive and points all of your storage stuff to OneDrive. The result is that all your files are backed up.
The result of the default setup is that all of your infected files are stored on One Drive. This doesn't help. Your files are still infected. There is no backup copy, only the infected copy, so they are not backed up. It doesn't do you any good to have the infected files there rather than here.
So here's our first file of proper backup: backups must store multiple versions going back in time, with old versions immutable.
Recently, Microsoft has offered an option to store old versions if you pay a subscription to Office. If you're paying for it already, you may want to look into that option.
> Windows Backup and Restore or Apple Time Machine which does pretty much the same thing.
For those unfamiliar, Time Machine uses a USB drive connected to your computer, or a network drive to store old versions. The interface is really nice and it's awesome when you realize you screwed up and deleted or overwrote an important file. It's the ultimate undo. When you have a fire, a burglary, a flood, or a ransomware infection, that'll take both your computer itself and the USB drive. So this isn't proper backup - you're not protected a good against most types of catastrophic loss. It's a really cool extension of ctrl-z, though, to get back that file you just messed up.
This illustrates proper backups are off site. I used to do backups for web sites. I pointed out that just in Texas alone, every year for the last four years there had been major disaster at a public datacenter. Anyone who had a server at one of these data centers and had their "backup" in the same datacenter lost everything. In one instance, I had to get creative in retrieving some customers' data from a datacenter after the company operating it failed to pay their lease and took off into the night.
Backups must be in a separate physical location - a fire, flood, or burglary will take or destroy everything in your office.
I mentioned before backups must be tested regularly. Backups that haven't been recently tested have a failure rate of about 50%, in my experience.
They also need to be automated, because most people only do manual systems properly for a little while, then try start slacking off and eventually "forget" to run a backup for six months.
Ransomware reminds us of another requirement - the system being backed up (which may get ransomware) can not have the ability to delete or modify the backups. Sending backups to a network drive just means the ransomware or disgruntled employee will destroy two copies of the data.
> That said, to be honest, I have absolutely no idea how to maintain good backups of my Linux systems.
After I sold one of my companies, I spent a year and half designing and building a very good backup for Linux systems. The new company backup up the web servers for hundreds of web sites. The backups were kept off site, they kept several versions, the protected system had no way to remove the backups, they were fully automated, and you could easily restore any files at any time to test it. Add a bonus, you could click a button and BOOT the backup - they were stored as virtual machines.
It's too bad my skills at running a business aren't nearly as good as my engineering skills. I was like Wozniak without Steve Jobs - I built something really cool, something really useful, but making a successful, stable company from it wasn't my forte. If you actually have a ton of Linux systems, and if you care about any them, maybe we should talk. I still have some pretty awesome backup software for Linux.
One technique for data sterilization is to convert to a different format. For example, converting a Word document to WordPerfect will make sure there are no macros, I believe. Then convert back. Even better, convert to plain text if possible, and leave it as plain text. JPG to bump, etc.
Absolutely you're right the best way to handle a rootkit is restore from a known-good backup. Just like you practiced, last month when you tested it when found and fixed the problem with backup system.
Unfortunately, 90% of people don't have a proper backup system. Probably over half of systems that are being "backed up" can't actually be restored because the backup media went bad a year ago or whatever.
For the people who don't have a solid backup:
> some IT professional who sells himself to a client by claiming he can remove this and leave the user's precious data intact?
What you definitely don't do is try to salvage the operating system and programs. Just re-install those. It was time to upgrade anyway. DATA *can* be painstakingly recovered. It's a heck of a lot easier if your data isn't mixed with code - no MS Office macros, etc. If you keep your data separate from executable code, it absolutely can be recovered, though it's very easy to slip up and let a potentially infected file through.
Most systems do not contain a hardware random number generator, yet they DO manage to produce cryptographically secure keys.
As it happens, a camera sensor in the dark (such as these wireless cameras, with the lens cover on) is pretty good hrng.
An example for clarity:
Bob: What's wrong?
Steve: I'm fighting with my wife.
It sounds like this is an identifier rather than an encryption key, but let's suppose we're talking about keys, and specifically private keys.
Yes, it's more secure to generate a private key on the device, so insider threats don't know the key. However, that makes it MORE likely to have duplicates, not less likely. Generating them externally, you can easily ensure you don't get repeats, or more easily, control the likelihood of repeats with a good random source.
If the device generates it's own key, the default is that two cameras with the same electronics will generate the same key. You have to put in significant work to come up with a pseudo random number from determinate electronics. Unless the device publishes something about the key, you can't be sure there are no duplicates.
Bank grade would be a four digit PIN.