Is it safe to let websites store personal information for you. Why not store the information on your own storage media that you control with your own hands? How long before Facebook is hacked? Would they even tell us about it when it happens? The websites have not proven they can safeguard personal information. Why should we keep giving it to them?
EHarmony Confirms Password Hack
11–20 of 33 posts
Re: EHarmony Confirms Password Hack
#12Couldn't password databases be implemented as hardened "appliances?" This wouldn't have to be sold as hardware, it could just be an install. The machine would only have the function of storing and verifying passwords, and secure communication with authorized clients. All apis could use fixed-length fields. Passwords themselves could be stored using a modified salting technique using a white-box version of block ciphe…
How many services use ldap with per-user controlled access, kerberos or radius for authenticating their users? Yeah... If we're not using what's available now, why would people start using specific appliances?
I know the list here has a wide range of possibilities and doesn't map exactly to what you describe. What I mean is that we can do things 10 times better than we do them now with off-the-shelf (or even, off-the-github) products right now. Yet there's still a lot of services authenticating by `SELECT ... WHERE user='" + $user + "' AND pass='" + $pass + "'`.
Re: EHarmony Confirms Password Hack
#13Is this newfound outpouring of confirmed hacks a result of the market becoming more blasé about leaked passwords, or is this just a statistical anomale?
I'm not going to trust these companies again, I closed my accounts with last.fm and linkedin, you get one shot with my data.
Re: EHarmony Confirms Password Hack
#14Couldn't password databases be implemented as hardened "appliances?" This wouldn't have to be sold as hardware, it could just be an install. The machine would only have the function of storing and verifying passwords, and secure communication with authorized clients. All apis could use fixed-length fields. Passwords themselves could be stored using a modified salting technique using a white-box version of block ciphe…
I think if you care enough about password security to know these appliances exist, you already know how to use a proper password storage scheme. The ones that we are seeing dumped were not even trying.
What the parent is talking about is basically a solution to the http://en.wikipedia.org/wiki/Principal%E2%80%93agent_problem. I don't think these password compromises were likely failures of management to say "let's build a secure system"; they were failures of the engineers told to "build a secure system" to know and care enough about building secure systems to learn about things like bcrypt/scrypt in the first place.
The solution to this, of course, is to make password security into its own industry, with its own principals who are incentivized to understand every facet of secure systems. This would resolve as the parent explains--third-party vendors selling these companies multi-million-dollar "password appliances" with installation, support contracts, and all of that brouhaha--and then bringing in their support engineers to teach the company's own people how to securely call into the appliance.
Re: EHarmony Confirms Password Hack
#15Any info on how these passwords were hashed? MD5, SHA*, salted, unsalted...?
Re: EHarmony Confirms Password Hack
#16Perhaps users would be better served by salting their passwords manually before signing up for any web services. If your usual throwaway password is "Passw0rd1", try "eharmonyPassw0rd1" for your eHarmony account, and "linkedinPassw0rd1" for your LinkedIn account.
At this point, I can't even tell if this is sarcasm.
Re: EHarmony Confirms Password Hack
#17Couldn't password databases be implemented as hardened "appliances?" This wouldn't have to be sold as hardware, it could just be an install. The machine would only have the function of storing and verifying passwords, and secure communication with authorized clients. All apis could use fixed-length fields. Passwords themselves could be stored using a modified salting technique using a white-box version of block ciphe…
I don't think the problem is that storing passwords is too hard, at least not for the majority of startups not dealing with PCI compliance. Setting up a user system with bcrypt/scrypt is pretty trivial. The problem is you have several apps that were built before "just use bcrypt" became a meme and switching to bcrypt or some kind of hardened "appliance" just isn't seen as a priority, especially if it would require changes in several legacy systems. It's like telling people to backup their databases. Everyone knows they should do it. It's not hard. But it doesn't directly bring in revenue so therefore some people will inevitably just never get around to it (until they get get hacked and it becomes a PR issue).
Re: EHarmony Confirms Password Hack
#18Perhaps users would be better served by salting their passwords manually before signing up for any web services. If your usual throwaway password is "Passw0rd1", try "eharmonyPassw0rd1" for your eHarmony account, and "linkedinPassw0rd1" for your LinkedIn account. At this point, I can't even tell if this is sarcasm.
It might help, but I think the cracking tools would simply get an update that tries `password` and `password` (and even `password`).
As the salt is guessable (as it is in your examples) it just turns into a cat-and-mouse game that the crackers win every time (since for every one of you there are probably 2 or more of them).
Re: EHarmony Confirms Password Hack
#19Is this newfound outpouring of confirmed hacks a result of the market becoming more blasé about leaked passwords, or is this just a statistical anomale?
Eclipse? Transit of Venus?* * (I know, I know: Wrong crowd. But take it as a tongue in cheek way of saying that it could be a "trend" with another explanation than either of the two you posit.)
That's fair, I just wonder if there's some valid research worth doing here to figure out what's going on. Hacks aren't exactly going down, after all, and if we knew at least one of the causes that we don't already know about now, security might be slightly easier.
Re: EHarmony Confirms Password Hack
#20Perhaps users would be better served by salting their passwords manually before signing up for any web services. If your usual throwaway password is "Passw0rd1", try "eharmonyPassw0rd1" for your eHarmony account, and "linkedinPassw0rd1" for your LinkedIn account. At this point, I can't even tell if this is sarcasm.
It might help, but I think the cracking tools would simply get an update that tries `password` and ` password` (and even `password `). As the salt is guessable (as it is in your examples) it just turns into a cat-and-mouse game that the crackers win every time (since for every one of you there are probably 2 or more of them).
One of the primary ideas behind salts is to render pre-generated rainbow tables useless. Using a salt like the OP mentioned meets this need.
Although I'm unsure to how useful and widely used pre-generated rainbow tables are with modern computing.