11 ms·
To Keep Passwords Safe from Hackers, Just Break Them into Bits
- meritt 14y agoSomeone needs to show these guys Stripe CTF 2.0 Level 8. https://github.com/stripe-ctf/stripe-ctf-2.0/tree/master/levels/8 https://github.com/stripe-ctf/stripe-ctf-2.0/tree/master/lev...
- trebor 14y agoWhat was the weakness of chunked storage of passwords? I thought that an adaptation of something like Shamir's Secret Share could work.
- ontoillogical 14y agoIn the CTF's implementation, the 2nd piece of the password would only be checked if the first one was correct. You could figure out how many different requests were made by correlating TCP sequence numbers. If only 1 request was made, the first piece was incorrect. If 2 requests were made, the 1st piece was correct, but not the second, etc... The attack was akin to a timing attack (but definitely not a timing attack).
- jarin 14y agoHaha, this is the first thing I thought of when reading this article. In reality, it would probably be difficult to execute on a live production server via the TCP port method. The artificial delay they added in to prevent timing attacks might cause a heavy load on the server, so if they leave that out that would be another possible attack vector.
- webreac 14y agoI enjoyed a lot stripe 2.0 and I have watched Dan Bone on coursera. In the article, they just split the password in two. 128bit/2 -> 64bits. This remains two much for brute force like TCP port method or timing attack.
- tedunangst 14y agoIf LinkedIn, the article's whipping boy for bad password storage, had somebody with the brains and capability to purchase and integrate this multi-machine password storage system, LinkedIn would have had somebody with the capability of implementing a secure password hashing system like pbkdf or bcrypt or scrypt and wouldn't need to buy a mega priced security solution from RSA.
- fleitz 14y agoAll they needed was someone with the intelligence necessary to type: gem 'devise' into a textfile.
- pjscott 14y agoLinkedIn is written almost entirely in Java, so Devise would not have worked out that well. Using something like jBCrypt would have been almost as easy, though -- if they'd thought of it from the beginning. The failure here is just that whoever wrote the auth code didn't know that it was a problem, or thought (incorrectly) that using something like bcrypt would be significantly more effort.
- JshWright 14y agoI'm not sure Rails would be the go-to platform is security is a primary concern...
- lawrencepit 14y agoSure thing: Security announcement: Devise v2.2.3, v2.1.3, v2.0.5 and v1.5.4 released http://blog.plataformatec.com.br/2013/01/security-announcement-devise-v2-2-3-v2-1-3-v2-0-5-and-v1-5-3-released/ http://blog.plataformatec.com.br/2013/01/security-announceme...
- fleitz 14y agoUpgrade immediately unless you are using PostgreSQL or SQLite3. So using a real database mitigated the entire issue. Secondly, this security issue doesn't allow you to retrieve every user's password in 8 hours.
- jiggy2011 14y agoCan't you just use bcrypt/scrypt and be done with it?
- fleitz 14y agoThat's really the sad part... technically it's a superior solution to bcrypt/scrypt but the reason why LinkedIn got pwned was because they MD5'd their passwords instead of bcrypt/scrypt.
- lonnyk 14y agoIf I remember correctly they were also not using a salt. They stated that "members whose passwords have not been compromised benefit from the enhanced security we just recently put in place, which includes hashing and salting of our current password databases."[1] [1] http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/ http://blog.linkedin.com/2012/06/06/linkedin-member-password...
- jarin 14y agoIt blows me away that nobody at LinkedIn had heard of rainbow tables, or that they didn't think it was THAT important.
- jrockway 14y agoThe problem is that when you make this mistake early, it's not easy to fix, since you don't have the passwords yourself. Though I guess they could have rainbow-table'd their own password database and migrated everything over to a better scheme, rather than waiting for users to successfully log in.
- bradleyland 14y agoI'm surprised common auth systems don't handle this more elegantly. It's possible to maintain a history of crypt methods and store that with the password data. The system can then keep track of which user records were created with older algorithms, and automatically update them when the user logs in, but not requiring an across-the-board password update. The process is completely transparent to the user.
- rdl 14y agoThreshold cryptography might be an interesting approach when you need to keep credentials (vs. hashes of credentials), but I'd probably go with keeping my credentials encrypted under keys stored in a hardware security module (HSM) with rules on access (rate limit, etc.), first. Vastly cheaper (even though HSM prices are generally a form of rape), and simpler.
- afhof 14y agoTalk is cheap. Let's see the math.
- amper5and 14y agohttp://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing by Adi Shamir, the "S" in RSA
- alanctgardner2 14y agoI like the little plug at the bottom for physical OTP devices, which completely neglects to mention that RSA is a leading player in this space. I wonder if the writer accidentally went the completely wrong direction with that sound bite.
- rorrr 14y agoSecurity by obscurity.
- jrockway 14y ago"Hi Alice, this is Bob from Ops. Can you reset the root password on storage-server-A and storage-server-B? The ticket is PCR-1337. Thanks."
- jlkinsel 14y agoIn theory if your'e going to the trouble of having different OSes on the two systems, you'll have separate admin staff, as well...
- uvdiv 14y agoIn theory if you're going to the trouble of hashing your users' passwords, you'll salt them too. None of us would be in this thread if these types of theories were true.
- rpearl 14y agoWhy in the world would there be a root password at all? "No, Bob, if you lost the private key associated with your ssh credentials you can send me a gpg-signed email or wait until morning when you can verify your identity physically."
- EthanHeilman 14y agoI'd really like to know more. I've looked around and can't find anything. Can anyone link to the paper they published on this?
- amper5and 14y agoAs I linked further down, this is probably based on Adi Shamir's (of RSA) threshold sharing scheme [1] [2]. Essentially, this approach splits any "secret" into n parts, requiring that k of them are necessary to reconstruct the original secret. It relies on the fact that k points are necessary to reconstruct a k-1 order polynomial. So if you hand out n points, with n > k, then any k of these points can be used to reconstruct the polynomial, whose y-intercept is the "secret". The coefficients of the polynomial are random. There are other [3] sharing schemes, and for the trivial k = n case, Shamir's scheme is probably overkill. [1] http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing [2, PDF] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.8910&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.... [3] http://en.wikipedia.org/wiki/Secret_sharing http://en.wikipedia.org/wiki/Secret_sharing UPDATE: Here are some links to RSA's "Distributed Credential Protection" offering [4] and the white paper [5] describing it. [4] http://www.emc.com/security/rsa-distributed-credential-protection.htm http://www.emc.com/security/rsa-distributed-credential-prote... [5, PDF] http://www.emc.com/collateral/software/white-papers/h11013-rsa-dcp-0812-wp.pdf http://www.emc.com/collateral/software/white-papers/h11013-r...
- jlkinsel 14y agoYeah...this is nice, but really who's gonna implement it? Only folks with a lot of resources and need to protect something more serious than passwords on a social network. Or organizations who are vulnerable to the RSA sales person attack. ;) As others have hinted - once you have folks sophisticated enough to do tricks like using multiple operating systems, you'd hope they're going to catch the basics...
- Shorel 14y agoI believe that in some future time the password of a social network will be one of the most important passwords a person can have. You can change banks easier than you can migrate all your contacts to another social network.
- rogerbinns 14y agoI'm confused by their logic. Customers are those who are unable to keep one set of servers appropriately secured and unable to mitigate compromises through the use of better techniques (eg bcrypt). So the solution is to run a second set of servers. Why would those be any better or differently secured?
- michaelhoffman 14y agoBecause this method makes RSA some money?
- Create 14y agosudo apt-get install ssss or sudo port install ssss
- olivier1664 14y agoMaybe it can keep safe weak password from dictionary attack. If a user has "pass" as password, BCrypt do not protect him once the attacker has an hash of its password. Maybe their 2 servers methods prevent that (I'm really not sure)
- rogerbinns 14y agoWhat leads you to believe that bcrypt is susceptible to hashing or rainbow tables? It uses salts and extremely expensive key setup (ie different for each password even if the original plaintext is the same). It is true that if the password is one of the most common such as "pass" or "password" then you'll be to tell if that is the case in a reasonable amount of time. However you could trivially do that testing without going to the lengths of breaking into and compromising systems. All this RSA mechanism does is split the password verification into two halves each with knowledge of about half the information necessary to compromise. In theory compromising one system won't help you - you need to do both. But that doesn't help against the weakest passwords since they can just be tried against the system. There are some good presentations on the bcrypt wikipedia page. Of note is that 1,000 password guesses per second per system is roughly what happens now, and that scrypt is better for some circumstances. By contrast legacy schemes have rates from 10 million to 2 billion per second - even something as modern as WPA has 100,000 guesses per second per system crackers. But back to the original point - a company with weak administration and security practises isn't going to get any better by doing more of it.
- fulafel 14y agoSounds a bit like "envaulting": http://en.academic.ru/dic.nsf/enwiki/10223648 http://en.academic.ru/dic.nsf/enwiki/10223648 This is from a crypto startup called Envault that was founded on the idea of splitting data in pieces - they keep a fraction of the ciphertext somewhere "in the cloud" and off the local storage of your device when not in use. This is advertised as being very very safe. I never heard any crypto guy with credentials comment on their tech though which is usually a bad sign...
- jpallen 14y agoNo doubt I'm missing something dumb, but would one get similar benefits from simply storing half of the password hash on one server, and half on the other? To authenticate the password, you would then just authenticate it against both servers which can tell you whether their half matches. What is the advantage of the technique described[1] in the article compared to this? [1] That's putting it a bit kindly. 'that we were told exists' might be more fair.