LinkedIn Password Leak: Salt Their Hide 192
CowboyRobot writes "Following yesterday's post about Poul-Henning Kamp no longer supporting md5crypt, the author has a new column at the ACM where he details all the ways that LinkedIn failed, specifically related to how they failed to 'salt' their passwords, making them that much easier to crack. 'On a system with many users, the chances that some of them have chosen the same password are pretty good. Humans are notoriously lousy at selecting good passwords. For the evil attacker, that means all users who have the same hashed password in the database have chosen the same password, so it is probably not a very good one, and the attacker can target that with a brute force attempt.'"
Standard practice? (Score:5, Insightful)
With something as high profile as Linkedin, how did it get missed?
Arent there audits,etc to check for this type of stuff?
Isnt it similar to releasing a range of cars, all of which have the same key (or something similar. Analogies are my weak point, as is the English language)
Re: (Score:3, Insightful)
This is LinkedIn, not your bank, not the government, nothing important.
If you use the same password on some bunk website as important things, then you deserve what you had, but if, for some reason, I used the same password for slashdot as LinkedIn, and someone hacks my slashdot, whatever. The thing to really worry about is what these companies do with all of our personal information.
Re: (Score:3, Insightful)
Even for others, its an important career development resource
Re:Standard practice? (Score:5, Insightful)
Education of users is a very, very good goal, especially when so many users don't fully understand the risks out there, but the first step in educating them is having empathy for their plight. Sure, victims learn the most valuable of lessons, but it would far better to have them learn to protect themselves *before* the damage is done.
Re: (Score:3)
It's technically true that many people are vulnerable because they don't know how important it is to protect themselves, but directly blaming them for it is counter-productive.
Your whole argument fails because LinkedIn isn't "many people".
LinkedIn is a multi-million user networking site for professionals.
Education of users is a very, very good goal, especially when so many users don't fully understand the risks out there, but the first step in educating them is having empathy for their plight.
LinkedIn has a goddamn team of coders and server monkeys.
Salting your hashes is really really basic stuff. It's at the level of "look both ways before crossing the street."
If you don't look both ways before crossing the street, it's your own damn fault for stepping in front of a car.
And yes, I'm comparing malicious hackers to cars. They will run you over if you give them a chance
Re: (Score:2)
Your whole argument fails because LinkedIn isn't "many people". LinkedIn is a multi-million user networking site for professionals.
Uhm.... I think you may be mis-informed. LinkedIn is simply Facebook for your career. No more and no less. Whether you're linked to highly professional expert and/or leadership types or somebody that flips burgers all day, it's all in the groups and contacts you make.
Because of this, you can be pretty sure not everybody with a LinkedIn account knows proper password selection techniques, or that their chosen professions require this knowledge anyway. Many of my contacts are technical contacts, but man
Re: (Score:3)
Not taking a jab at you personally, but I've never understood the "you deserve what you got, silly victim!" mentality. No victims *deserve* to be victimized. Sure, they could have taken better steps to protect themselves, but I can just as easily say "you deserve that cancer you got" for not getting regular boob or prostate squashings. It's technically true that many people are vulnerable because they don't know how important it is to protect themselves, but directly blaming them for it is counter-productive.
Would you feel better if I said you "earned" being victimized? You smoke two cartons of Camels a week in this day and age, and you don't just deserve cancer, you earned it. You evidently put a lot of effort into pretending that the fact that your cancer was all but inevitable somehow didn't apply to you. Enjoy your winnings!
Re: (Score:2)
Re: (Score:3)
This is LinkedIn, not your bank, not the government, nothing important.
Many (most?) people use the same id/password combination on multiple accounts. If I know everyone's id/password for Linkedin, then for maybe half those people I can now login to their bank.
People are stupid. Expecting them to be non-stupid is unrealistic. So good security has to accommodate stupidity. That is why even throw-away sites need to have good security.
Re: (Score:2)
Re: (Score:3)
They need to stop password reuse, but they won't. Users do not get paid for choosing passwords, but coders do get paid for writing code. If coders do their job poorly, blame lies with the coders. Expect stupidity, allow for genius.
I'm paranoid enough that I make up fake answers for security questions, and password hints are intentionally misleading, while still enough for me to figure out what it means. I also do not re-use passwords.
But I am not normal. That is why, when I have to write some sort of a
Re: (Score:2)
This is LinkedIn, not your bank, not the government, nothing important.
Except my bank has security questions that ask would-be infiltrators for personal information about me--the sort of personal information that can be found on LinkedIn, or that contacts on LinkedIn are likely to know.
Re: (Score:2)
My security question answers are randomly generated, twelve char alpha-numerics, just like my passwords (like, but different), unique for every site. It can be a PITA, but given the lousy security on sites I use, keeping them separate as much as possible just seems like a good idea.
Re: (Score:2)
I never give security questions the kind of thing they ask for. If they want my mother's maiden name, they might get "Cheverolet Caprice" (a car I have never owned), or the name of the neighbors's dog that I hate. I really doubt that they are going to check to see if I gave a valid name.
Actually, I do this too. But I'm betting a lot of LinkedIn users don't.
Re: (Score:2)
I think everyone fails to keep this in perspective.
This is LinkedIn, not your bank, not the government, nothing important.
That argument might hold water if salting user passwords was difficult, expensive, or not commonly-known best practice. (All of which really translate to "expensive" -- either in developer time or server resources.) Then you'd have a justification -- a low-security site is expending less effort on security. But it's not. It's simple, it's cheap, and anyone who is allowed to make a password database should already know that it needs to be done.
Re: (Score:3)
What ? All the banks I've used (3 so far) allows me to transfer money directly from their web site. Yes it can be tracked, but I'm quite sure it can be hard to reverse.
Re: (Score:2)
All of the banks I've used require 4-5 days, verification, and send email notice (sometimes a post card) when you're transferring to an account for the first time. I'm not saying people should be flippant about their bank login info--but banks seem to do a decent job of notifying users about risky changes to their account (as long as your email isn't compromised, too).
Re: (Score:2)
Have you never noticed the "online bill pay" button on your bank's web site? It makes EFT payments to companies, but, if you want to send a payment to someone without an EFT account, most services will automatically cut and mail a physical check. Anyone who can get into your account and make an online payment can mail a check made out to whatever fake ID they have on hand, or whatever fake-ish company name they set up.
Re:Standard practice? (Score:5, Insightful)
Isnt salting and hashing a standard practice for passwords even for low security stuff?
It is.
I have worked for 4 companies where I was involved with a database that contained user passwords. Before I arrived, none of those companies used salts, and only one even hashed the passwords. When I explained it to my fellow programmers, it was the first time they had ever heard of the concept.
Security and best practices are an academic concepts that are not taught in school. Most people don't really care about security until it affects them. Slashdot is an unusual cross-section of people who tend to be security-minded so what appears to be common knowledge here is not representative of the software industry.
Re: (Score:2)
Best practices aren't academic concepts, they are industry concepts. It's true that there are a lot of cowboys in any industry that don't follow best practices, but that doesn't mean they are "academic".
Re: (Score:2)
I wouldn't say that password-hashing is a best practice in my industry. Note, that my industry has nothing to do with making computer software, though it makes a lot of computer software in the process, and buys quite a bit from other companies who have incentive to deliver the features customers are looking for, and not the ones they should be looking for.
If I had to guess I'd imagine that the majority of systems at my company that store passwords do not hash them. At best they encrypt them, which is vir
Re: (Score:2)
The 2 companies I've worked at were both very security focused. Though, one was big expensive SAN systems (they had been encrypting network traffic since at least 1998 for the device management), and the other company does network security (IPS/IDS) and they are extremely paranoid with how data is stored and transmitted around.
I guess it's a matter of the type of company you work at and the background/enthusiasm of the people you work with.
Re: (Score:3)
To further one of my anecdotes: One of the companies in my list was very paranoid. They used big expensive SAN systems and had been encrypting network traffic forever. They even escrowed customer data they thought they should not hold themselves. Yet they still didn't salt passwords.
I can only conclude that hashing and salting is less well known than encrypting.
Re: (Score:2)
Re: (Score:3)
Security and best practices are an academic concepts that are not taught in school. Most people don't really care about security until it affects them.
And in turn, corporations don't care about security until is costs them money. Look at Microsoft, they didn't give a flip about security until sometime after Windows XP when that OS was getting owned left and right by malware. Which started to cost them, albeit indirectly.
How exactly will this cost LinkedIn? If it is being ridiculed in the press, they'll just ride it out and not care. If people leave in droves and their service becomes less valuable, or advertisers/customers jump ship, then they'll give a c
Re:Standard practice? (Score:4, Interesting)
Security and best practices are an academic concepts that are not taught in school...Slashdot is an unusual cross-section of people who tend to be security-minded so what appears to be common knowledge here is not representative of the software industry.
^^THIS!!!^^
I took a senior-level computer security class while working on my C.S. degree in college, and it was largely a waste of time. We spent half the semester working our way through various historical encryption algorithms trying to get *to* asymmetrical encryption (you know, Caesar's belt, various ROT-x ciphers, etc. -- i.e., stuff that should have been covered in the first week, maybe). We spent most of the rest of the semester dissecting DSA and RSA, and maybe two weeks talking about covert channels. We spent next to no time talking about one-way hashes, and salts were a completely foreign concept to me when I discovered them two or three years later when I started using Linux. As far as best practices for real-world computer security? I don't think that was ever even a FOOTNOTE in any of my C.S. courses.
Maybe I just went to a crappy school, but IMHO, my college education was woefully inadequate for the real world. Pretty much everything I use on a day-to-day basis was learned on my own, outside of college.
Re: (Score:3)
Half the trouble I had as a security developer was trying to educate/convince other developers that making an effort in this area was necessary. Some of them weren't familiar with the basic concepts, but even they were, it's hard to drive home the idea of defense in depth. There is a tendency to think that if the information is inside your database, or behind your firewall, or protected by other means, then it's not worth spending a lot more effort in additional protection. But of course, you are one exploi
Re: (Score:2)
No. Hashing is, but salting is not.
Most people barely understand that passwords need to be hashed, and how to use the hash value. These people certainly don't understand why. If they did, they'd know that salting is important.
There are still plenty of places where passwords are stored in plain text. Sometimes, it's appropriate. Sometimes, it's not. But knowing when is appropriate for what situation is the key, and that's what most people (in general, not just developers and authentication) lack.
Re: (Score:2)
Isnt salting and hashing a standard practice for passwords even for low security stuff?
With something as high profile as Linkedin, how did it get missed?
Arent there audits,etc to check for this type of stuff?
Isnt it similar to releasing a range of cars, all of which have the same key (or something similar. Analogies are my weak point, as is the English language)
Just because something is standard practice means it is followed. It seems to me like security practices are the first to be thrown out because "well none of the users will notice it anyhow." Best security is to assume you are going to get hacked or suffer data theft and design the system such that nothing critical can be gleaned from looking at a simple dump of the database. The fact that they got caught on something so horrifically basic is inexcusable.
The CTO should probably be updating his resume. Oh so
Re: (Score:2)
It's because they bootstrapped LinkedIn at some point and hired a bunch of subpar indian devs to design security for them on the cheap.
Most likely they hired a bunch of subpar indian developers to put the site together and they didn't even consider security.
How about stop using passwords (Score:4, Interesting)
or BrowserID (Score:5, Interesting)
https://www.browserid.org/ [browserid.org]
It's the closest I've seen to SSH Keys. That's all I want, SSH Keys for web auth.
Re: (Score:3, Insightful)
Not gonna happen. All big sites want to be OpenID *provider*, but none of them will accept OpenID Logins.
Re: (Score:2)
Not gonna happen. All big sites want to be OpenID *provider*, but none of them will accept OpenID Logins.
true, but with more and more reputation-busting exploits like this, you'd think they'd be happy to pass the password-storage problem to someone else. No more "we were hacked and lost all our passwords" news.
Maybe the issue is that they just don't trust the providers to be secure themselves, though if that's the case, it's still better for the site (but not the user).
Re: (Score:2)
Re: (Score:2)
Correct Horse Battery Staple
Re: (Score:2)
Correct Horse Battery Staple
0bcf1df3cb81df3908d74d46b7fa9dd036b3b3c2
Well sure, if you know what to compute ahead of time, it's easy to get the hash. That's the point of a hash. But how long does it take to get to that hash even if you know that the user is typing only four distinct words?
...
...
... ... ...
/usr/share/dict
Aachen Aachen Aachen Aachen
Aachen Aachen Aachen Aachen's
Aachen Aachen Aachen's Aachen
Aachen Aachen Aachen's Aachen's
Aaliyah Aaliyah's Aachen Aachen
aardvark aardvark Aardvark Aachen
Correct Horse Battery staple
Correct Horse Battery Staple
$ wc -l
Re: (Score:2)
I'll one-up you on that -- client-side browser certificates have been possible since the first days of SSL on the Internet.
Why aren't we using them to authenticate users and completely secure a link?
Time to start scrambling passwords (Score:3)
I think I will start visiting websites I no longer use, and deactivate my accounts. If that doesn't work, I'll fill the "user profile" with a bunch of nonsense & scramble the password. It worries me that over the last ~20 years I've visited a bunch of places and left behind details about myself. I never used linked-in but I imagine if I did, I'd be in potential trouble now (leaked info).
Re:Time to start scrambling passwords (Score:4, Informative)
Re: (Score:2)
...and you don't even hear about when those little sites get breached, if they're even aware of the fact at all.
Re: (Score:2)
...and you don't even hear about when those little sites get breached, if they're even aware of the fact at all.
And I'll bet some of the big ones.
Re: (Score:3)
Re: (Score:2)
I find that very few sites have a deactivate option. I think your backup plan will be the most common approach.
Re: (Score:2)
Re: (Score:2)
Like your reputation once your account starts recommending Xtenz to all your contacts?
Re: (Score:2)
That's problematic, but everyone getting those messages will realize you got hacked anyway.
I apparently had a windows live account that got hacked. Not really sure when, not really sure how since I don't recall having used it for years. it sent out some spam before MS shut it down and some friends where kind enough to let me know it was sending out stuff. Everyone was well aware that the account was hacked, and to most people its not obvious if its your fault you got hacked or the fault of the site owner
Daft Question (Score:5, Insightful)
This may well be a very daft question but:
It appears that the default is to use a simple solution when people are first developing their websites.
Isn't this what libraries are for? Why isn't the default secure method in development environments/website template/distros etc to use a much more secure method?
Why is there no standard library that I just say (for example) store_user_password($user_name); and it takes care of it?
If there is such a thing why isn't it more universally used and why blame the website implementers for what is a dev environment/toolkit/whatever problem?
If the technology the article talks about has been known since the 80s why isn't it the standard in all the modern environments? And whatever the answer I'm not sure the blame rests in the users of however they develop this(unless they are writing their website in C based CGI...).
Re: (Score:3)
There ARE libraries like that. From the article:
But what was secure back in 1995, when computers had processors like Pentiums or Pentium Pros [wikipedia.org] operating at around 200 MHz, is not secure in 2012, when computer processors in the Sandy Bri [wikipedia.org]
Re: (Score:2)
There are a lot of libraries. Some of them are simple, and some aren't. Most developers probably don't know which library would be easiest to drop in. So, it's easiest for them to just use the md5() function or something like that. Especially because library developers usually have no sense of when their library is simple or when it's complex.
I can't tell you how many times I've just implemented something for which a library already existed. And it probably took longer than using the library would have, but
Re: (Score:2)
This still sounds like a weak argument. Heck, even PHP has single-call [php.net] salted hashing with Blowfish these days. The problem is poor education - developers don't even know what hashing and salting is, or why it's important for passwords, so they don't even bother to look up how to do it right.
Re: (Score:2)
Or they did that in 2002, to launch a website in 2003, and have no idea how to transition a hashed password database from one system to another, which is a more difficult problem.
The thing is: we still don't know where this hack is from. 6.5 million of 160 million is a very small set of the data. Are *all* linkedin passwords SHA1 with no salting? If so changing your password doesn't do a whole lot of good, and that's a huge disaster for the whole outfit. Is one of their services (say LinkedIn syria) usi
Re: (Score:2)
If you design things properly [wikipedia.org], not hard at all [kernel.org].
Basically, all hashes in the database should be stored in the format of:
$id$salt$encrypted
"id" is a code that tells you which hash was used. You can use the standard "crypt" identifiers, or make up your own if those aren't good enough.
"salt" is the unique salt for each user
Resume (Score:5, Funny)
Re:Resume (Score:5, Funny)
You can put it on everybody's resume!
Re: (Score:3)
Re: (Score:2)
The significance of LinkedIn (Score:5, Interesting)
This LinkedIn hack could lead to even more high-profile hacks, due to the unique user base that LinkedIn has
On most sites (like Facebook) most of the stupid passwords will belong to stupid 13 year old kids with nothing of value to hackers, but on a site like LinkedIn you are more likely to get the password for some computer illiterate corporate executive. In many cases this is the same simplistic password he uses at work, where he insisted he be given admin-level access on all of their servers "because hes an executive"
Computer security is always about the weakest link in the chain, and when one of those "links" partied his way though business college and never thinks twice about password reuse, you have a pretty weak chain. LinkedIn is like an x-ray showing the hackers who the weak links are.
Re: (Score:3)
On the flip side, if you don't reuse your passwords, you're never going to remember how to access all 200 sites that require it. Most people barely remember their username, nevermind their password.
There's a bigger problem here than just password reuse. It has to do with passwords as an authentication factor in general.
Re: (Score:2)
On the flip side, if you don't reuse your passwords, you're never going to remember how to access all 200 sites that require it.
That's only if you do it without thinking about it first (i.e. use 200 random passwords). It's very easy to come up with your own system of starting with a base password then add things to the end (or beginning) that makes it unique for the particular site (i.e. using an abbreviation of the site name). You can even do this with different levels of base passwords (in case you are paranoid of a hacker specifically targeting you) one secure and one insecure. If you think that is still hard to remember, you can
Re: (Score:2)
Re: (Score:3)
Even if you change your password now what does that get you? If they're still unsalted SHA1 any minimally competent man in the middle attack will be able to get the hash, and then your password, as if it was part of this release.
If linkedIn actually has a different security system live and these are all old accounts who haven't changed passwords or the like, well then you have some idea what's going on. But changing your password from one unsalted SHA1 hash not tied to an account to another unsalted SHA
Re: (Score:2)
On the flip side, if you don't reuse your passwords, you're never going to remember how to access all 200 sites that require it. Most people barely remember their username, nevermind their password.
That's what Keepass and 1Password are for.
Re: (Score:2)
How many sites do you *really* need to log in to outside of your own personal machine? Memorize those and use some sort of mechanical system for remembering the rest.
This could be as low-tech as a 3x5 index card that you keep tucked away in an envelope at home. Or a folded over scrap of paper in your walle
Not exactly (Score:3)
low-salt (Score:2)
Mental image (Score:2)
seems the md5crypt guy just posted to bugtraq (Score:3)
Resume Posted to Linkedin (Score:2)
Experience: Director if IT Security for a large Social Media Product.
Objective: A position where I can apply my experience and lessons learned in a fast paced and dynamic environment, targeting a large customer base. ::Hired:: By Facebook.
Premium Users (Score:2)
I have a question, though... (Score:2)
The file going around is simply a pile of hashes, no logins. Did the crackers get both? Or did they just get the hashes?
Because the hashes may as well be piles of random data if you can't pair them with a login.
I have not heard a peep about the logins themselves. Are we just assuming they were taken?
--
BMO
Re: (Score:2)
I have not heard a peep about the logins themselves. Are we just assuming they were taken?
Yep - plan for the worst, hope for the best.
Couldn't this just be a hoax? (Score:2)
Think about it. 6 million unsalted password hashes without matching use data. If this is real password data, how big is the chance that someone would find their password in there?
Perhaps as big as the chance that you get a Google hit when you search for your password?
AFAIK all we have is:
- Someone posting a list claiming it's from LinkedIn
- Some people confirming that the hash of their LinkedIn password is on that list
That doesn't really prove anything, right?
- People tend to pick similar passwords
- People
Re:Faulty Logic (Score:5, Insightful)
I think you might be missing the point about duplicate passwords--it's an argument FOR salting the hashes.
Re: (Score:3)
Re: (Score:2)
This point about making password hashing take a whole second is critical. For some reason, the geniuses in charge of our Internet security are totally screwing this up. Take my GPG private key, for example. I have to encrypt the damned thing with a humongous pass phrase, because some dork, who you would expect to know something about security (having written GPG), didn't bother making the private key's decryption key a compute intensive hash of my pass phrase. This allows attackers to do efficient brute
Re:Faulty Logic (Score:4, Informative)
Re: (Score:2, Insightful)
Re:Faulty Logic (Score:5, Insightful)
Both the summary and article are being stupid about the reason for salting in hashed passwords. It's main benefit isn't hiding two same password. It's main purpose is to make brute force much more work,
Yes, but you should also mention that salts with a large amount of entropy also protect against Rainbow tables [wikipedia.org] and other forms of pre-computed hashed passwords. Make sure you have enough entropy in your salt(128 bits is very high) to prevent these kinds of attacks.
I'd recommend a randomly generated salt for each password, and not based on some user details. This guarantees a large amount of entropy in the salt. Some people also recommend an added site wide salt as well that's not stored in the same place as the password (embedded in the code for instance). This might increase your security a bit, but it's going to cost you quite a bit in added complexity.
Re: (Score:2)
Hmm, funny, that's exactly how I described my system last wednesday in an earlier thread on the subject. The added complexity is not a problem at all, the extra password is only stored in the authentication server (which runs on a different system than the database contaning the hashed passwords.
Re: (Score:2)
Re:Faulty Logic (Score:5, Informative)
Salting does not make brute forcing one password more work. It does make bruteforcing a list of passwords more work, however.
Re: (Score:2)
It seems to me that generating huge rainbow tables extremely quickly should be quite doable with a large botnet, because it's inherently a highly parallelizable task.
The raw horsepower advantage of criminal botnets probably makes a lot of the existing password dogma obsolete. Criminals won
Re: (Score:2)
I'm curious, what methods do people generally use for coming up with a salt?
Also, since you obviously need to be able to retrieve the salt in order to validate a login, where do you store it? In a database along with the hashed concatenated salt+password? (RDBMS, LDAP, doesn't matter in this case, a database is a database is a database... a place to store data)? That is you have the unencrypted salt (so you can retrieve it again) possibly in the same table as the hashed value? Since you can't decrypt a hash
Re: (Score:2)
When someone is trying to get into the system by brute force, are they not just throwing a ton of passwords (even via rainbow tables) at the established authentication system?
It seems to me that the client would have to know the salt ahead of time (i.e. some time well before they even try to log in) to create a secure salted password to send to the login service. And wouldn't this then be kind like a pseudo public key encryption? If the client doesn't have the salt then they are just sending a plain passwo
Re:Do they understand how hashes work? (Score:5, Informative)
Do they understand how hashes work?
Yes, Poul-Henning Kamp understand how hashes work. Much, much, much better than you do. But if you feel compelled to lecture the writer of MD5crypt on your wonderful insights into how hashes work, please, feel free.
Re: (Score:2)
One to Many... But a lot of those Many are characters you are not going to type with your keyboard.
Re: (Score:2)
I guess you don't use terminal type 3270 too often. Control E is often configured to clear your field from the cursor to the end. So your password would be saved as what you typed minus the Ctrl-E... Unless you intentionally go back a few characters and do the ctrl-e last.
Back in the olden days of DOS my password often had Alt-219 atl-176 alt-177 and alt-178
Re: (Score:2)
Huh?
sha1sum blah = 5bf1fd927dfb8679496a2e6cf00cbe50c1c87145
sha1sum 5bf1fd927dfb8679496a2e6cf00cbe50c1c87145 = 9dbc5291ce0269baafbf68a6346b5510a1b30860
sha1sum 9dbc5291ce0269baafbf68a6346b5510a1b30860 = caa4e37211fda75d91b9bf3231f9fbeb434d56e8
[...]
Re: (Score:2)
Re: (Score:2)
Web development and security is a 2nd or 3rd year class. You only get 4 years before you're expected to go off and be able to work on any reasonable system. Developing a new salt or hash algorithm is a 4th year and grad school problem, knowing how to use them is 2nd or 3rd (depends on your school and where it fits with other courses).
For my undergrad web development was a 3rd year course (so they assumed you knew data structures already, but that could have been second semester of second year too). Secur
Re: (Score:2)
You only get 4 years before you're expected to go off and be able to work on any reasonable system.
My attitude was that I had 4 years to learn enough to be in a position where I could start to learn how to work on a reasonable system. 12 years on and I still feel like a rookie.
Maybe I should just give up and pick grapes instead?
Re: (Score:3)
Salting only protects you from precomuted "rainbow" brute force methods which means if you have a big enough table your password is cracked in seconds to minutes rather than oh I don't know what is the average for your typical password? Hour, day..two days? week tops...? Does this difference really mean anything substaintial to the vicitim?
Now I may be wrong, but that would only be the case if the salt was stored with the hashes, correct? Which to me seems rather dumb (from a security perspective, not a performance one). To maximize the benefit of salts, the password hashed and their associated salts should be stored in two different databases, running on different servers so that a hacker would have to compromise both to get access to the list. Lock down the Salt DB server so that's it's only able to communicate with the Hash DB server (and
Re: (Score:3)
Your not really adding security by splitting it up, a well protected server that only stored uuid and salted hashes would do the same.
Re: (Score:2)
Re: (Score:2)
A different random salt per hash is expected (otherwise it's nearly useless). In the good better best of security you have salted hashes stored along with everything else, a box that gets sent the password and uuid (or whatever unique identifier is used), and a box that is sent a uuid and random string to hash with the password and the client does that same. Splitting up the hash parts onto two separate servers does very little as they are both involved and one have to send it's part of the hash to the ot
Re: (Score:2)
These passwords can still be brute force at todays mega ridiculous n core, GPU accelerated rates at extremely low cost.
Go ahead, try bruteforcing high-cost bcrypt.
Re: (Score:2)
Actually, it does a few things:
* It makes rainbow tables ineffective.
* It prevents identification and lookup of common passwords (e.g., by pasting the SHA-1 hash into Google)
* It make cracking a list of N passwords a factor of N harder.
The last is fairly important for large database leaks. A single password is no harder to compute if you add salt, but if you're brute-force cracking against the entire password list (which is what you want to do), it's a factor of a million slower because you can't just compu
Re: (Score:3)
Salting only protects you from precomuted "rainbow" brute force methods which means if you have a big enough table your password is cracked in seconds to minutes rather than oh I don't know what is the average for your typical password? Hour, day..two days? week tops...? Does this difference really mean anything substaintial to the vicitim?
To a single victim no. But you've taken the complexity of the problem from hacking a password to hacking 6 million passwords each taking as long. So to the 'average' victim your expectation time before being hacked is 3 million times longer, on a 6 million element set, than one that wasn't salted. There are just over 31 million seconds in a year. So even if your password takes 1 second to crack you've still bought yourself about a month. If it takes a day... well you'll be dead before it's brute force
Re: (Score:2)