WHY THE FUCK WAS SHE CONDUCTING OFFICIAL STATE DEPARTMENT BUSINESS ON A PRIVATE EMAIL SERVER IN THE FIRST PLACE?!?!
Because state department servers are not secure. The Clinton family learned from experience that their political opponents have free access to dig through anything that's stored on official servers.
Being subject to constitutional oversight isn't "insecure", it's "working as intended". Proper definitions of security include making information available to the people who are supposed to have access to it, as well as keeping it out of the hands of those who aren't.
I also said *after a manufacturer has released an update*, the process of doing the QA at the telecom level shouldn't take a significant percentage of the 90 days.
Okay, I stand corrected. I agree with that... at least if the OEM did a decent job. A little while ago talked to the heads of QA of two major US MNOs, who both commented that they also thought that's how it should be, but experience has shown them that they can't trust the OEMs not to screw things up, so they have to do really thorough QA.
FWIW, a bunch of OEMs at the same meeting also agreed that things need to change, so I'm hopeful that over the next couple of years they will. Google is trying to push them by announcing a formal support policy for Nexus devices. It's interesting to note that the new support policies announced by Google and Samsung are the first in the industry -- including Apple, which has no formal update policy for iOS devices (though in practice they do a great job). It's a sign of things to come, I think.
(Aside: Many think that Google and Samsung created their update policies in response to Stagefright. Not possible. Given the legal and financial implications of such policies, they take a long time to set up.)
It's a lot easier to double a small number than it is to double a big one.
True, but when states where the Republicans are gaining more control are decreasing, that is bad. They hate things they don't understand. They want to remain ignorant. That is why they are destroying so many tech jobs.
Is that why the most Republican state in the country is #2 in growth? #3 is pretty red, too. #1 is moderately blue.
(Note: I live in Utah, but am not a Republican. Though I do tend to vote for more Republicans than Democrats.)
Whether something is the fastest growing has a lot to do with where it started. It's a lot easier to double a small number than it is to double a big one.
True, but in the case of Utah, it's already pretty large. 20 years ago, in the hey day of Novell and Word Perfect, Utah was actually #2 behind California in software revenue (total, not per capita), and while it declined quite a bit as those companies died, it never went away. Their failure created lots of tech startups because, frankly, after living in Utah not many people want to move to California, while the flow the other direction is pretty large, and because the CS programs of the University of Utah and Brigham Young University kept pumping out the talent supply that created Novell and Word Perfect in the first place.
So being in second place means tech in Utah is pretty healthy. In my experience Minneapolis is also a pretty hot spot, and has been for a long time, as is Omaha. So I'd say all three are cases of significant tech industries experiencing healthy growth, not small areas just getting started.
Doesn't it let you essentially let you find out if you've had (since this boot?) up to 256 bits of entropy?
No, not in any way I can see.
You can ask it whether it has had an amount so long as it's less than 256 bits and you can force it to return failure if you ask for an amount it hasn't yet reached.
That's not what it says. It says:
By default, getrandom() draws entropy from the/dev/urandom pool.
[...] If the/dev/urandom pool has been initialized, reads of up to 256 bytes will
always return as many bytes as requested and will not be interrupted
by signals
So, it's good that if the call will block unless the pool has been initialized (unless you give it the GRND_NONBLOCK) flag. But "pool has been initialized" doesn't tell you anything about how much entropy has been gathered except that it's non-zero. The bit about 256 byte (note: byte, not bit) reads always returning has nothing to do with entropy available, it's just an assurance that reads up to that size will be fast and atomic with respect to signals.
Not really. getrandom() doesn't tell you how much entropy is in the pool, or if you've ever had a certain amount of entropy. It does allow you to wait until the pool has been "initialized", which is good, and maybe good enough, but it's not the same.
And if you want your baby quicker, you just need more women.
I'm sure that in some cases staffing actually is an issue, but I know that in many cases it's really not the problem... and in some the problem is that stuff just takes time, and it's really not possible to go faster. For example, you do some testing, find a problem and then can't usefully test all of the other stuff around that problem until it's fixed. Then you find and fix another problem, which uncovers a subtle, previously-hidden flaw elsewhere, invalidating testing you thought you'd completed. Automated testing helps, but not everything can be tested that way, and automated testing has its own issues.
I work on Android, on the core OS, so I have a little familiarity with these processes as they apply to Nexus devices. One of the biggest considerations that goes into decisions about what to change and when, and when to release what, is "soak time": how long do we have to test and experiment on the device or upgrade or patch before we push it out? This time isn't measured in person-hours, it's measured in calendar weeks, because however much staff you have, there's kind of a maximum rate at which you can find, analyze and address (fix, or otherwise, depending) issues.
For major releases, we really want to have "soak time" of several *months*, during which almost nothing changes. For small security patches that "shouldn't" affect anything else, we still want at least several days, preferably a couple of weeks. And that's if nothing goes wrong.
Jump to the modern phone, and you find that if people use features that allow them to "check in" from a given location, they only use that feature when they choose to use that feature. They do not state their location everywhere they go, they use it selectively, to essentially boast, or because they earn a living through online connectedness and marketing and it is to their advantage to share far too much information with the rest of us.
I have Google Location History turned on, which records everywhere I go, but I do it for other reasons which include (among others):
So that my wife and a few other people I share my location with can find out where I am at any moment
So when I want to know where I was and what I did a few days ago I can look it up in my Maps timeline
So Google Now can track my location to alert me when I need to leave for appointments, etc.
Nothing to do with boasting or marketing; it's for convenience, mine and that of my family.
Oh, forgot to mention the "certifi-gate" vuln. That one is also overrated. It doesn't give root (though perhaps could be a good start to an exploit chain) and depends on your OEM having done something dumb (I don't recall if Samsung did).
With three major, ecosystem-wide exploits published just in the last week or so, why can I still not get root on my S6 Active?
Honestly... at least part of it is because the exploits are not nearly as serious as described. Stagefright appears to be unexploitable on a device with proper ASLR, which your S6 has. This deserialization vuln isn't sufficient to get root (though perhaps it could be chained with another exploit). The pingpong vuln should be enough to get you persistent root... but by the time someone has packaged a nice tool to do it, Samsung will probably have pushed an update.
If you really want to root your device, you should buy one that is unlockable from the manufacturer. This includes all Nexus devices but several other OEMs also sell unlockable devices. Then you do what you like with it.
Note that I don't actually recommend running rooted. It pretty severely handicaps the Android security model. I really, really recommend against disabling SELinux enforcing mode. Rooting plus "setenforce 0" throws much of the security model out the window. You're more than welcome to do that if you like, of course, but it's a risk.
Google has already patched the SDKs, but I think any apps made with them have to be updated as well.
(Android security team member here.)
There's a platform-level fix which involves both Google Play Services changes and core OS changes. The Google Play Services changes were pushed out in early June. The core OS changes were pushed to Nexus devices in last week's update, and other OEMs have had the fix (including backported versions of the fix for older Android versions) since June and should be delivering it with their own updates.
The best solution is not to have so many passwords. Single sign-on (SSO) should be able to consolidate many of them. For the rest, most are probably fairly low-value, and needn't be rotated.
Personally I have one password for work and another for my personal e-mail account that I consider really high value and rotate annually (I also use two-factor auth on both of those). I also rotate my password manager password annually. Then I have a second tier of important passwords (bank, etc.). Those I don't rotate regularly, but I do generate long, random, non-memorable passwords for them and keep them in my password manager. At any hint of strangeness, I change them, and I change them all every two or three years.
Then I have a couple of passwords I use on all the sites I don't care about (like slashdot). I would have only one password for all of those sites, but they don't all agree on password requirements.
If your company hasn't got a decent SSO system deployed, or if you work on systems belonging to a lot of different clients, or for some other reason have no way to consolidate your important logins, I don't have any good suggestions for you.
You didn't propose anything at all. You just complained about TLS and said SSH is great, not even substantiating either of those.
The reason for my lengthy posts is to engage in a technical conversation, but you seem incapable of doing anything but whining. If you'd like to actually respond to my points, perhaps propose how an SSH-style scalable system would work, or explain why you think the proposed fixes for the CA system (including the others I didn't mention... surely you're well aware of them), I'll be happy to discuss.
Can that software be made to wait two or three minutes to allow entropy to build up?
Even better, the software can be made to watch the entropy pool (there's an ioctl for that) and wait until there's enough. And it can also be made to re-seed periodically while running in order to limit any vulnerability arising from bad estimates early.
Why do passwords need to be rotated? I have read lots of things saying that you should but never seen a compelling argument.
The longer you keep a password, the more likely it is that it has been compromised in some way. Rotating it closes the window of vulnerability.
All of the reasons for rotating passwords are more appropriately handled by changing password immediately. Rotating passwords happens regardless of an incident, which is wasteful, and only ensures that somebody locks up after the horse has left the barn.
You're assuming that you have some indication that your password is compromised. You may not, which means the barn won't get locked. Unlike the horse/barn analogy, there is often value in locking up even after the attacker has been in.
With that said, if you have a decent password and reasonably-good password security habits (e.g. don't use it on multiple systems), I don't think there's any need to rotate your password more than annually.
I think there's a fundamental misunderstanding of biometrics and biometric security that is prevalent throughout much of the industry, and it's often expressed as "biometrics are identifiers, not passwords!", though usually with more exclamation points, or the verbal equivalent, except when the even more foolish version "biometrics are passwords" is used.
These statements are wrong. Biometrics are not identifiers. They're lousy identifiers, actually, since identifiers need to be unique and consistent, while biometrics aren't either. Biometrics are also not passwords. Passwords rely on secrecy and need to be rotated. Biometrics are not secret and cannot be rotated.
But, if biometrics don't fit into either of these buckets we're accustomed to, if they're not usernames and not passwords doesn't that mean they're useless? No, it does not.
Biometrics are authenticators. Passwords are also authenticators, but they operate on different principles, validating information that is expected to be a secret. Biometrics attempt to validate the presence of a physical body that is the one expected. What's funny about this to me is that humans, in general, are extremely comfortable with biometric identification and authentication because it's the way we identify and authenticate everyone around us all the time. But we've trained ourselves to think differently about these issues in the context of computer security. (Note that personal identification is considered the best form of authentication in physical security systems as well... the biometric auth systems built into our heads are extremely hard to fool at close range with more than a few seconds' interaction).
Biometric authentication provides security without relying on the secrecy of your fingerprints, because they aren't. You leave them everywhere you go all over everything you touch. Including, by the way, your phone. They provide security because it is supposed to be hard for anyone else to use your fingerprints, even if they know exactly what they look like, to unlock your phone. That is, the security comes from the meat/sensor interface, not from the content of the data delivered via that interface.
This fact points out some rather obvious potential exploits. Since making gummy fingers isn't particularly hard, and since phone sensors aren't very good at distinguishing between real fingers and fake fingers, the security level isn't very high against an attacker who is willing to go to the effort of lifting a print and making a fake finger. It's also not good against an attacker willing to crack the phone open and replay image data directly to the system, bypassing the sensor.
Fingerprints provide a very different security model than passwords. They're stronger against casual attackers (can't be shoulder surfed; often hard to phish), but potentially weaker against more sophisticated attackers, and don't rely on secrecy.
With this proper contextualization, it's clear that the "attacks" referenced in the article are non-issues. Leaking your fingerprints isn't a security problem, it's a privacy problem. Fingerprints are like any other PII (personally-identifiable information) on your phone. The device should secure PII against remote extraction, and should make it reasonably hard for local attackers to get. But when the attack begins with, step 1, "root the device", I just tune out, because of all of the PII on my phone, my fingerprints are among the least important.
Absolutely not. My argument is that the TLS authentication architecture is broken beyond repair.
The SSH authentication system does not scale, but it is sound, and it could be made to scale without changing the base principle. The TLS authentication can not be repaired without changing it from the core.
There is no SSH authentication "system". It's purely manual. How could it scale for use by billions of people who know nothing about security and are more than happy to click "OK" just to get that annoying dialog out of the way? Particularly without forcing far-reaching changes in the rest of the web infrastructure.
Also, I disagree that TLS' authentication architecture is broken beyond repair, for two reasons. First, in actual practice for the vast majority of uses, it's not broken at all. Given the scope and scale of TLS usage, actual breaks due to CA system failures are vanishingly rare, and mostly confined to nation-state actors who, frankly, are extremely hard to defeat regardless of the design.
Second, we have some excellent proposals as to how we can shore up the few issues that have cropped up. Google's Certificate Transparency project, plus more care by browser makers of whose signing certs they package will address the worst of the problems. If that's not enough, we could stand up something like Marlinspike's Convergence... not as a replacement for the CA infrastructure but as an additional, stand-beside layer of protection.
Unless you can define some architecture that both scales as well as CA-based PKI and has none of the flaws of CA-based PKI, and doesn't require retooling apparently-unrelated parts of the web, then we're clearly better off adding more layers of protection on the CA system instead of throwing it out and starting over. Actually, since whatever you come up with will have its own, as-yet-unknown flaws, I'd say we're better off even if you could articulate such a system.
Finally, I think SSH authentication is overrated. How often do you actually check your SSH key fingerprints? Unless you're very, very different from most users of SSH, you log in, get a message about a key, think for half a second "Is this actually the first time I've connected to this computer? I think so..." and hit 'y'. And if you actually are that much more conscientious than the vast majority of SSH users, good for you, but that just further shows you're not the right person to decide how the world should authenticate.
In practice, even when presented with the nasty message caused when the server's key changes, few users dig into the issue unless they have reason to know that the key should not have changed. Instead, they delete the offending key from their authorized_hosts file and try again. And we're talking about sysadmins who are nominally competent and security-conscious.
Tell me how that's going to work with your grandma. Scalability issues aside, how is she going to react when a key changes? At best browsers, etc., will make bypassing the warning message hard to do, freaking users out and causing system administrators to avoid rotating keys (a bad thing). In reality it'll be some equivalent of "delete that bad key and get the new one."
SSH authentication is okay for its intended audience. Not ideal, but okay. But it would result if far less security than the current system if applied to the rest of the world.
It's not about not trusting the hardware to execute the instructions. If the NSA were to backdoor the RNGs, they wouldn't do it by making the RNGs produce bad output on command... that would be too easy to detect. Instead, they'd just reduce the entropy of the output, all the time, but not so much that it's detectable. For example, perhaps for every 128-bit output, the RNG generates one of 2^40 128-bit blocks. Now, if you use that RNG's output as an AES key, say, then your key is easily brute-forceable by someone who knows which 2^40 keys it might be.
Of course, this sort of back door is easy to defeat; just make a conservative estimate of the entropy you think you get from the RNG, make it low enough that if it really were that low it would be easily detectable and then apply an entropy-preserving compression function to enough output to get as many bits as you need. This is why I think it's unlikely that the NSA bothered.
I do this for living. This presentation is FUD and not applicable for 99% of all configurations. Sure, some headless system with a solid state drive will encounter 'at rest' issues if they idle long enough. This why/dev/random design blocks. For that 1% cases you can always mix Intel RdRand, or Freescale SEC sources.
The real issue with Entropy is that developers keep using/dev/urandom, then all bets are off, as you need to guarantee that system always has sufficient entropy.
Your comment inadvertently highlights the problem.
Developers don't use/dev/random because it blocks, and there's almost never any point to waiting. Once the pool has accumulated a few hundred bits of entropy, there's no reason not to use/dev/urandom.
But blindly using/dev/urandom is dangerous because in some (fairly rare) cases the system will not have any entropy.
The solution is to use/dev/urandom, but only after verifying that the pool has some entropy. Ideally, it would be nice to have an API that allows you to find out how many total bits of entropy have been gathered by the system, regardless of how many remain in the pool at any given point in time. If the system has managed to accumulate a few hundred bits, just use/dev/urandom and get on with life. If it hasn't, use/dev/random and block.
Hmm, it occurs to me that maybe we should just add a third character device, maybe/dev/gerandom (for Good Enough random), which provides exactly this behavior. Then we could just tell developers to use that./dev/random would be for the particularly paranoid./dev/urandom would be deprecated. The reason not to just change the behavior of/dev/urandom rather than adding a new device is because software assumes that it will never block, where/dev/gerandom will just hardly ever block.
Entropy estimation isn't a black art. Here is how you do it: take SP 800-90B recommended tests - Markov, Compression, Frequency, Collision, and Partial Collection, collect 1 million samples, then take minimum of the individual test results. Or just do Markov. As long as you take care to analyze raw data (not conditioned), you can find our what is your entropy.
That doesn't tell you anything about the entropy of the data. At all. Try this: Take your favorite CPRNG and seed it with all zeros. Then generate all of the samples you need for exhaustive testing and run all of the tests. The completely deterministic output will pass with flying colors.
While you're at it, try this test as well: Take the output of a known quantum random process (thermal noise, etc.). Don't filter or process it in any way, use the raw data. Now run the tests on it. The truly random data will fail.
Those tests only validate the statistical properties of the samples. If they all pass, you can be pretty sure that the data is uniformly-distributed and free of biases. But they don't (and could never!) say anything about whether or not the output is random in any degree. Entropy is a measure of how much actual unpredictability exists in the stream. Your deterministic CPRNG seeded with a known value has beautifully uniform and bias-free output, but generates zero entropy. Your quantum mechanics-based TRNG isn't uniform and has various biases, but generates a lot of entropy.
Here's part of the black art: Tell me how much entropy the TRNG produces. It's less than one bit of entropy per bit of output. How much less?
I can easily condition the TRNG's output to make it uniform and bias-free (at least as far as standard statistical tests can tell), but that does not increase the entropy of the output. To estimate the entropy you need to analyze the TRNG's raw output both statistically and by examining the physical processes. One you have a reasonable guess, you can then condition the data to ensure that it does have a bit of entropy per bit, by compressing it in a way that reduces the output size but doesn't discard entropy.
But the kernel doesn't do anything like that. Instead, it looks at its incoming data sources and tries to estimate from the data itself how much entropy the data contains. It tries to be conservative, and the process of mixing the new data into the entropy pool is effectively an entropy-preserving compression function. But that estimation? Black art. Oh, there's some mathematical justification, but it rests on a lot of assumptions that are invalid to some degree.
There should be plenty of network packets to ensure the accumulation of at least a kilobit of entropy during the normal course of operation.
Sure, eventually. But what happens later doesn't matter if Apache has already fired up its workers and they've already initialized their OpenSSL CPRNGs. This is why OpenSSL should re-seed periodically -- and why BoringSSL does re-seed periodically. So if you start with the CPRNG in a predictable state, at least it doesn't stay that way.
I can't find any list online of linux entropy sources that are used.
This is one of the other points the researchers noted: There's very little information available on how it all works other than the source code. Of course, the source code is both authoritative and exhaustive, but not as accessible as some good documentation would be.
The first thing I notice about that article is that it help spreading the misconception that HTTP is the only use of Internet and HTTPS the only encryption scheme.
I must say, I feel much safer knowing my SSH sessions are not HTTPS-encrypted, because the certification mechanism is completely broken.
The HTTPS certification infrastructure has problems, but to say that SSH is better because it doesn't have one at all is rather bizarre. If you'd like exactly the same sort of security from HTTPS that you get from SSH you can verify HTTPS certificate IDs manually, and you can install a browser extension that warns you when they change.
Slashdot Mirror
WHY THE FUCK WAS SHE CONDUCTING OFFICIAL STATE DEPARTMENT BUSINESS ON A PRIVATE EMAIL SERVER IN THE FIRST PLACE?!?!
Because state department servers are not secure. The Clinton family learned from experience that their political opponents have free access to dig through anything that's stored on official servers.
Being subject to constitutional oversight isn't "insecure", it's "working as intended". Proper definitions of security include making information available to the people who are supposed to have access to it, as well as keeping it out of the hands of those who aren't.
I also said *after a manufacturer has released an update*, the process of doing the QA at the telecom level shouldn't take a significant percentage of the 90 days.
Okay, I stand corrected. I agree with that... at least if the OEM did a decent job. A little while ago talked to the heads of QA of two major US MNOs, who both commented that they also thought that's how it should be, but experience has shown them that they can't trust the OEMs not to screw things up, so they have to do really thorough QA.
FWIW, a bunch of OEMs at the same meeting also agreed that things need to change, so I'm hopeful that over the next couple of years they will. Google is trying to push them by announcing a formal support policy for Nexus devices. It's interesting to note that the new support policies announced by Google and Samsung are the first in the industry -- including Apple, which has no formal update policy for iOS devices (though in practice they do a great job). It's a sign of things to come, I think.
(Aside: Many think that Google and Samsung created their update policies in response to Stagefright. Not possible. Given the legal and financial implications of such policies, they take a long time to set up.)
It's a lot easier to double a small number than it is to double a big one.
True, but when states where the Republicans are gaining more control are decreasing, that is bad. They hate things they don't understand. They want to remain ignorant. That is why they are destroying so many tech jobs.
Is that why the most Republican state in the country is #2 in growth? #3 is pretty red, too. #1 is moderately blue.
(Note: I live in Utah, but am not a Republican. Though I do tend to vote for more Republicans than Democrats.)
Whether something is the fastest growing has a lot to do with where it started. It's a lot easier to double a small number than it is to double a big one.
True, but in the case of Utah, it's already pretty large. 20 years ago, in the hey day of Novell and Word Perfect, Utah was actually #2 behind California in software revenue (total, not per capita), and while it declined quite a bit as those companies died, it never went away. Their failure created lots of tech startups because, frankly, after living in Utah not many people want to move to California, while the flow the other direction is pretty large, and because the CS programs of the University of Utah and Brigham Young University kept pumping out the talent supply that created Novell and Word Perfect in the first place.
So being in second place means tech in Utah is pretty healthy. In my experience Minneapolis is also a pretty hot spot, and has been for a long time, as is Omaha. So I'd say all three are cases of significant tech industries experiencing healthy growth, not small areas just getting started.
90 days is enough time. You said "days or weeks at most". That is not feasible.
Doesn't it let you essentially let you find out if you've had (since this boot?) up to 256 bits of entropy?
No, not in any way I can see.
You can ask it whether it has had an amount so long as it's less than 256 bits and you can force it to return failure if you ask for an amount it hasn't yet reached.
That's not what it says. It says:
By default, getrandom() draws entropy from the /dev/urandom pool.
[...] If the /dev/urandom pool has been initialized, reads of up to 256 bytes will
always return as many bytes as requested and will not be interrupted
by signals
So, it's good that if the call will block unless the pool has been initialized (unless you give it the GRND_NONBLOCK) flag. But "pool has been initialized" doesn't tell you anything about how much entropy has been gathered except that it's non-zero. The bit about 256 byte (note: byte, not bit) reads always returning has nothing to do with entropy available, it's just an assurance that reads up to that size will be fast and atomic with respect to signals.
Not really. getrandom() doesn't tell you how much entropy is in the pool, or if you've ever had a certain amount of entropy. It does allow you to wait until the pool has been "initialized", which is good, and maybe good enough, but it's not the same.
And if you want your baby quicker, you just need more women.
I'm sure that in some cases staffing actually is an issue, but I know that in many cases it's really not the problem... and in some the problem is that stuff just takes time, and it's really not possible to go faster. For example, you do some testing, find a problem and then can't usefully test all of the other stuff around that problem until it's fixed. Then you find and fix another problem, which uncovers a subtle, previously-hidden flaw elsewhere, invalidating testing you thought you'd completed. Automated testing helps, but not everything can be tested that way, and automated testing has its own issues.
I work on Android, on the core OS, so I have a little familiarity with these processes as they apply to Nexus devices. One of the biggest considerations that goes into decisions about what to change and when, and when to release what, is "soak time": how long do we have to test and experiment on the device or upgrade or patch before we push it out? This time isn't measured in person-hours, it's measured in calendar weeks, because however much staff you have, there's kind of a maximum rate at which you can find, analyze and address (fix, or otherwise, depending) issues.
For major releases, we really want to have "soak time" of several *months*, during which almost nothing changes. For small security patches that "shouldn't" affect anything else, we still want at least several days, preferably a couple of weeks. And that's if nothing goes wrong.
Stuff takes time.
I am reminded of a quote about safety being a tyrant's tool...
Where's the tyrant? I'm telling you go nuts if you want to do it, just don't come whining if it costs you.
Jump to the modern phone, and you find that if people use features that allow them to "check in" from a given location, they only use that feature when they choose to use that feature. They do not state their location everywhere they go, they use it selectively, to essentially boast, or because they earn a living through online connectedness and marketing and it is to their advantage to share far too much information with the rest of us.
I have Google Location History turned on, which records everywhere I go, but I do it for other reasons which include (among others):
So that my wife and a few other people I share my location with can find out where I am at any moment
So when I want to know where I was and what I did a few days ago I can look it up in my Maps timeline
So Google Now can track my location to alert me when I need to leave for appointments, etc.
Nothing to do with boasting or marketing; it's for convenience, mine and that of my family.
Oh, forgot to mention the "certifi-gate" vuln. That one is also overrated. It doesn't give root (though perhaps could be a good start to an exploit chain) and depends on your OEM having done something dumb (I don't recall if Samsung did).
With three major, ecosystem-wide exploits published just in the last week or so, why can I still not get root on my S6 Active?
Honestly... at least part of it is because the exploits are not nearly as serious as described. Stagefright appears to be unexploitable on a device with proper ASLR, which your S6 has. This deserialization vuln isn't sufficient to get root (though perhaps it could be chained with another exploit). The pingpong vuln should be enough to get you persistent root... but by the time someone has packaged a nice tool to do it, Samsung will probably have pushed an update.
If you really want to root your device, you should buy one that is unlockable from the manufacturer. This includes all Nexus devices but several other OEMs also sell unlockable devices. Then you do what you like with it.
Note that I don't actually recommend running rooted. It pretty severely handicaps the Android security model. I really, really recommend against disabling SELinux enforcing mode. Rooting plus "setenforce 0" throws much of the security model out the window. You're more than welcome to do that if you like, of course, but it's a risk.
Google has already patched the SDKs, but I think any apps made with them have to be updated as well.
(Android security team member here.)
There's a platform-level fix which involves both Google Play Services changes and core OS changes. The Google Play Services changes were pushed out in early June. The core OS changes were pushed to Nexus devices in last week's update, and other OEMs have had the fix (including backported versions of the fix for older Android versions) since June and should be delivering it with their own updates.
The best solution is not to have so many passwords. Single sign-on (SSO) should be able to consolidate many of them. For the rest, most are probably fairly low-value, and needn't be rotated.
Personally I have one password for work and another for my personal e-mail account that I consider really high value and rotate annually (I also use two-factor auth on both of those). I also rotate my password manager password annually. Then I have a second tier of important passwords (bank, etc.). Those I don't rotate regularly, but I do generate long, random, non-memorable passwords for them and keep them in my password manager. At any hint of strangeness, I change them, and I change them all every two or three years.
Then I have a couple of passwords I use on all the sites I don't care about (like slashdot). I would have only one password for all of those sites, but they don't all agree on password requirements.
If your company hasn't got a decent SSO system deployed, or if you work on systems belonging to a lot of different clients, or for some other reason have no way to consolidate your important logins, I don't have any good suggestions for you.
You didn't propose anything at all. You just complained about TLS and said SSH is great, not even substantiating either of those.
The reason for my lengthy posts is to engage in a technical conversation, but you seem incapable of doing anything but whining. If you'd like to actually respond to my points, perhaps propose how an SSH-style scalable system would work, or explain why you think the proposed fixes for the CA system (including the others I didn't mention... surely you're well aware of them), I'll be happy to discuss.
Can that software be made to wait two or three minutes to allow entropy to build up?
Even better, the software can be made to watch the entropy pool (there's an ioctl for that) and wait until there's enough. And it can also be made to re-seed periodically while running in order to limit any vulnerability arising from bad estimates early.
Passwords rely on secrecy and need to be rotated.
Why do passwords need to be rotated? I have read lots of things saying that you should but never seen a compelling argument.
The longer you keep a password, the more likely it is that it has been compromised in some way. Rotating it closes the window of vulnerability.
All of the reasons for rotating passwords are more appropriately handled by changing password immediately. Rotating passwords happens regardless of an incident, which is wasteful, and only ensures that somebody locks up after the horse has left the barn.
You're assuming that you have some indication that your password is compromised. You may not, which means the barn won't get locked. Unlike the horse/barn analogy, there is often value in locking up even after the attacker has been in.
With that said, if you have a decent password and reasonably-good password security habits (e.g. don't use it on multiple systems), I don't think there's any need to rotate your password more than annually.
I think there's a fundamental misunderstanding of biometrics and biometric security that is prevalent throughout much of the industry, and it's often expressed as "biometrics are identifiers, not passwords!", though usually with more exclamation points, or the verbal equivalent, except when the even more foolish version "biometrics are passwords" is used.
These statements are wrong. Biometrics are not identifiers. They're lousy identifiers, actually, since identifiers need to be unique and consistent, while biometrics aren't either. Biometrics are also not passwords. Passwords rely on secrecy and need to be rotated. Biometrics are not secret and cannot be rotated.
But, if biometrics don't fit into either of these buckets we're accustomed to, if they're not usernames and not passwords doesn't that mean they're useless? No, it does not.
Biometrics are authenticators. Passwords are also authenticators, but they operate on different principles, validating information that is expected to be a secret. Biometrics attempt to validate the presence of a physical body that is the one expected. What's funny about this to me is that humans, in general, are extremely comfortable with biometric identification and authentication because it's the way we identify and authenticate everyone around us all the time. But we've trained ourselves to think differently about these issues in the context of computer security. (Note that personal identification is considered the best form of authentication in physical security systems as well... the biometric auth systems built into our heads are extremely hard to fool at close range with more than a few seconds' interaction).
Biometric authentication provides security without relying on the secrecy of your fingerprints, because they aren't. You leave them everywhere you go all over everything you touch. Including, by the way, your phone. They provide security because it is supposed to be hard for anyone else to use your fingerprints, even if they know exactly what they look like, to unlock your phone. That is, the security comes from the meat/sensor interface, not from the content of the data delivered via that interface.
This fact points out some rather obvious potential exploits. Since making gummy fingers isn't particularly hard, and since phone sensors aren't very good at distinguishing between real fingers and fake fingers, the security level isn't very high against an attacker who is willing to go to the effort of lifting a print and making a fake finger. It's also not good against an attacker willing to crack the phone open and replay image data directly to the system, bypassing the sensor.
Fingerprints provide a very different security model than passwords. They're stronger against casual attackers (can't be shoulder surfed; often hard to phish), but potentially weaker against more sophisticated attackers, and don't rely on secrecy.
With this proper contextualization, it's clear that the "attacks" referenced in the article are non-issues. Leaking your fingerprints isn't a security problem, it's a privacy problem. Fingerprints are like any other PII (personally-identifiable information) on your phone. The device should secure PII against remote extraction, and should make it reasonably hard for local attackers to get. But when the attack begins with, step 1, "root the device", I just tune out, because of all of the PII on my phone, my fingerprints are among the least important.
Absolutely not. My argument is that the TLS authentication architecture is broken beyond repair.
The SSH authentication system does not scale, but it is sound, and it could be made to scale without changing the base principle. The TLS authentication can not be repaired without changing it from the core.
There is no SSH authentication "system". It's purely manual. How could it scale for use by billions of people who know nothing about security and are more than happy to click "OK" just to get that annoying dialog out of the way? Particularly without forcing far-reaching changes in the rest of the web infrastructure.
Also, I disagree that TLS' authentication architecture is broken beyond repair, for two reasons. First, in actual practice for the vast majority of uses, it's not broken at all. Given the scope and scale of TLS usage, actual breaks due to CA system failures are vanishingly rare, and mostly confined to nation-state actors who, frankly, are extremely hard to defeat regardless of the design.
Second, we have some excellent proposals as to how we can shore up the few issues that have cropped up. Google's Certificate Transparency project, plus more care by browser makers of whose signing certs they package will address the worst of the problems. If that's not enough, we could stand up something like Marlinspike's Convergence... not as a replacement for the CA infrastructure but as an additional, stand-beside layer of protection.
Unless you can define some architecture that both scales as well as CA-based PKI and has none of the flaws of CA-based PKI, and doesn't require retooling apparently-unrelated parts of the web, then we're clearly better off adding more layers of protection on the CA system instead of throwing it out and starting over. Actually, since whatever you come up with will have its own, as-yet-unknown flaws, I'd say we're better off even if you could articulate such a system.
Finally, I think SSH authentication is overrated. How often do you actually check your SSH key fingerprints? Unless you're very, very different from most users of SSH, you log in, get a message about a key, think for half a second "Is this actually the first time I've connected to this computer? I think so..." and hit 'y'. And if you actually are that much more conscientious than the vast majority of SSH users, good for you, but that just further shows you're not the right person to decide how the world should authenticate.
In practice, even when presented with the nasty message caused when the server's key changes, few users dig into the issue unless they have reason to know that the key should not have changed. Instead, they delete the offending key from their authorized_hosts file and try again. And we're talking about sysadmins who are nominally competent and security-conscious.
Tell me how that's going to work with your grandma. Scalability issues aside, how is she going to react when a key changes? At best browsers, etc., will make bypassing the warning message hard to do, freaking users out and causing system administrators to avoid rotating keys (a bad thing). In reality it'll be some equivalent of "delete that bad key and get the new one."
SSH authentication is okay for its intended audience. Not ideal, but okay. But it would result if far less security than the current system if applied to the rest of the world.
So, essentially, your argument is that the SSH method does not scale. I agree.
It's not about not trusting the hardware to execute the instructions. If the NSA were to backdoor the RNGs, they wouldn't do it by making the RNGs produce bad output on command... that would be too easy to detect. Instead, they'd just reduce the entropy of the output, all the time, but not so much that it's detectable. For example, perhaps for every 128-bit output, the RNG generates one of 2^40 128-bit blocks. Now, if you use that RNG's output as an AES key, say, then your key is easily brute-forceable by someone who knows which 2^40 keys it might be.
Of course, this sort of back door is easy to defeat; just make a conservative estimate of the entropy you think you get from the RNG, make it low enough that if it really were that low it would be easily detectable and then apply an entropy-preserving compression function to enough output to get as many bits as you need. This is why I think it's unlikely that the NSA bothered.
I do this for living. This presentation is FUD and not applicable for 99% of all configurations. Sure, some headless system with a solid state drive will encounter 'at rest' issues if they idle long enough. This why /dev/random design blocks. For that 1% cases you can always mix Intel RdRand, or Freescale SEC sources.
The real issue with Entropy is that developers keep using /dev/urandom, then all bets are off, as you need to guarantee that system always has sufficient entropy.
Your comment inadvertently highlights the problem.
Developers don't use /dev/random because it blocks, and there's almost never any point to waiting. Once the pool has accumulated a few hundred bits of entropy, there's no reason not to use /dev/urandom.
But blindly using /dev/urandom is dangerous because in some (fairly rare) cases the system will not have any entropy.
The solution is to use /dev/urandom, but only after verifying that the pool has some entropy. Ideally, it would be nice to have an API that allows you to find out how many total bits of entropy have been gathered by the system, regardless of how many remain in the pool at any given point in time. If the system has managed to accumulate a few hundred bits, just use /dev/urandom and get on with life. If it hasn't, use /dev/random and block.
Hmm, it occurs to me that maybe we should just add a third character device, maybe /dev/gerandom (for Good Enough random), which provides exactly this behavior. Then we could just tell developers to use that. /dev/random would be for the particularly paranoid. /dev/urandom would be deprecated. The reason not to just change the behavior of /dev/urandom rather than adding a new device is because software assumes that it will never block, where /dev/gerandom will just hardly ever block.
Entropy estimation isn't a black art. Here is how you do it: take SP 800-90B recommended tests - Markov, Compression, Frequency, Collision, and Partial Collection, collect 1 million samples, then take minimum of the individual test results. Or just do Markov. As long as you take care to analyze raw data (not conditioned), you can find our what is your entropy.
That doesn't tell you anything about the entropy of the data. At all. Try this: Take your favorite CPRNG and seed it with all zeros. Then generate all of the samples you need for exhaustive testing and run all of the tests. The completely deterministic output will pass with flying colors.
While you're at it, try this test as well: Take the output of a known quantum random process (thermal noise, etc.). Don't filter or process it in any way, use the raw data. Now run the tests on it. The truly random data will fail.
Those tests only validate the statistical properties of the samples. If they all pass, you can be pretty sure that the data is uniformly-distributed and free of biases. But they don't (and could never!) say anything about whether or not the output is random in any degree. Entropy is a measure of how much actual unpredictability exists in the stream. Your deterministic CPRNG seeded with a known value has beautifully uniform and bias-free output, but generates zero entropy. Your quantum mechanics-based TRNG isn't uniform and has various biases, but generates a lot of entropy.
Here's part of the black art: Tell me how much entropy the TRNG produces. It's less than one bit of entropy per bit of output. How much less?
I can easily condition the TRNG's output to make it uniform and bias-free (at least as far as standard statistical tests can tell), but that does not increase the entropy of the output. To estimate the entropy you need to analyze the TRNG's raw output both statistically and by examining the physical processes. One you have a reasonable guess, you can then condition the data to ensure that it does have a bit of entropy per bit, by compressing it in a way that reduces the output size but doesn't discard entropy.
But the kernel doesn't do anything like that. Instead, it looks at its incoming data sources and tries to estimate from the data itself how much entropy the data contains. It tries to be conservative, and the process of mixing the new data into the entropy pool is effectively an entropy-preserving compression function. But that estimation? Black art. Oh, there's some mathematical justification, but it rests on a lot of assumptions that are invalid to some degree.
There should be plenty of network packets to ensure the accumulation of at least a kilobit of entropy during the normal course of operation.
Sure, eventually. But what happens later doesn't matter if Apache has already fired up its workers and they've already initialized their OpenSSL CPRNGs. This is why OpenSSL should re-seed periodically -- and why BoringSSL does re-seed periodically. So if you start with the CPRNG in a predictable state, at least it doesn't stay that way.
I can't find any list online of linux entropy sources that are used.
This is one of the other points the researchers noted: There's very little information available on how it all works other than the source code. Of course, the source code is both authoritative and exhaustive, but not as accessible as some good documentation would be.
The first thing I notice about that article is that it help spreading the misconception that HTTP is the only use of Internet and HTTPS the only encryption scheme. I must say, I feel much safer knowing my SSH sessions are not HTTPS-encrypted, because the certification mechanism is completely broken.
The HTTPS certification infrastructure has problems, but to say that SSH is better because it doesn't have one at all is rather bizarre. If you'd like exactly the same sort of security from HTTPS that you get from SSH you can verify HTTPS certificate IDs manually, and you can install a browser extension that warns you when they change.