Lessons Learned From Cracking 2M LinkedIn Passwords

An anonymous reader writes "Qualys researcher Francois Pesce used open source password cracker John the Ripper to try to crack SHA-1 hashes of leaked LinkedIn passwords. He ran the John the Ripper default command on a small default password dictionary of less than 4,000 words. The program then switched to incremental mode based on statistical analysis of known password structures, which generated more probable passwords. The results? After 4 hours, approximately 900,000 passwords had been cracked. Francois then ran numerous iterations, incorporating older dictionaries to uncover less common passwords and ended up cracking a total of 2,000,000 passwords."

Comments

Do not use standard passwords

[Anonymous Coward]

Surely this is not news.

Re:Do not use standard passwords

[Anonymous Coward]

It's a bit more than that if you bothered to read the summary:

The program then switched to incremental mode based on statistical analysis of known password structures, which generated more probable passwords

So standard passwords aside, go read about Markov chains, which JtR can utilize to bruteforce passwords that follow human rememberability standards.

Re:Do not use standard passwords

[synapse7]

or passwords developed by patterns. If you're password is not 20 random characters, it will probably be cracked with minimal effort from even a "journalist".

Re:Do not use standard passwords

[Anonymous Coward]

Surely this is not news.

It will stop being news when people stop doing it by the millions, which is to say "never".

Re:Do not use standard passwords

[Anonymous Coward]

It's a bit more than that if you bothered to read the summary:

The program then switched to incremental mode based on statistical analysis of known password structures, which generated more probable passwords

So standard passwords aside, go read about Markov chains, which JtR can utilize to bruteforce passwords that follow human rememberability standards.

The lesson from the article is "Always salt your password hashes". I'm not sure what you're going on about, any password can be memorized.

Re:Do not use standard passwords

[Richard_at_work]

The problem is, even passwords that would have been considered "non-standard" 5 years ago is now easily crackable - according to GRC, a password I used 5 years ago consisting of ten characters, alpha numeric, mixed case and a symbol would take just an hour or so to crack. That was quite eye opening.

So what next?

Re:Do not use standard passwords

[Qzukk]

Salting doesn't stop brute force crackers like JtR, it only stops attackers from using a rainbow table and/or discovering that two people have the same password.

The real lesson here is just because your password database is hashed (with or without salt) doesn't mean you should let just whoever download the thing.

Re:Do not use standard passwords

[Shetan]

So what next?

Two factor authentication.

Re:Do not use standard passwords

[Anonymous Coward]

It's a bit more than that if you bothered to read the summary:

The program then switched to incremental mode based on statistical analysis of known password structures, which generated more probable passwords

Thank you, Anonymous Coward. Of course I was only referring to default dictionaries, and not to other dictionaries or known password structures. Thank you so much for clarifying.

So standard passwords aside, go read about Markov chains, which JtR can utilize to bruteforce passwords that follow human rememberability standards.

I think I may have a few relevant textbooks at home.

Re:Do not use standard passwords

[hodet]

mod this shit up. this is the answer right here.

Re:Do not use standard passwords

[Kjella]

Well there's two ways here, online and offline cracking. I imagine LinkedIn has some kind of policy to stop people doing millions of authentication attempts online. If they get the PW from linkedin and can crack it offline then IMO linkedin's security has already failed. If you can get the passwords the hacker can probably get most anything else, so it's just damage control - don't reuse the password on anything you care about. In fact it's a bad idea anyway because you've no idea if someone with legal access at linkedin is snooping passwords to steal other accounts.

I'm guessing my account was in there and my password was weak, but they couldn't access my email, they couldn't access my online bank, post some crap on linkedin if you want but that's probably not going to be more than an "embarrassing moment" and then explaining my account was hacked. And the other services I use hte same password for, wow you can now impostor me on a few forums and whatnot. It's the kind of identity theft I can live with, to be honest. I'm far more concerned about my PC being hacked or entering my important passwords on a scam site than I am about my linkedin password going public.

Re:Do not use standard passwords

[ciderbrew]

My house is "secure" but if you are able to start hitting it with industrial equipment and take the roof off my choice of front door key doesn't matter.
When you can down load the whole password file and brute it off line, its just a matter of time. Time to wait for tech to get better and time to press the big red go button to run the code on the bit of fast(n) tech.

So type in a password you couldn't possible recall and each and every time you want to go back to the site - request a new password. This may be a stupid idea; but I end up doing it for a a few sites and I don't even bother to recall the crap I typed in. If I had to log into it every day I'd change, but some (most) sites are just not worth the effort. Protect sites that can rip money from you.

Re:Do not use standard passwords

[Moses48]

If they don't know your salt (code based) and you don't allow people to do multiple login attempts on your site, it does effectively stop brute force attacks at your passwords even if your salted hashes get out in the open. Still not the best idea to give out your database.

Re:Do not use standard passwords

[Anonymous Coward]

The real lesson here is just because your password database is hashed (with or without salt) doesn't mean you should let just whoever download the thing.

Genius. Pure genius. I hope the NSA snaps you right up. It's people like you with keen intellects that can come up with such a conclusion (that no one else has ever even considered) that will save this great nation of ours. Thank you. Thank you.

I'm going to go and change my setup so that my password databases aren't visible to the Internet anymore. It's just incredible. Are you the result of a Mensa genetic engineering experiment or something?

Re:Do not use standard passwords

[Hadlock]

[blockquote]So what next?[/blockquote]So assume your password is going to be compromised eventually (the bigger the service, the greater that chance approaches 1), use a different, randomized password for each website, and rely on "forgot your password?" links for when your browser's cookie times out.
 
For most websites, the "forgot your password?" link + checking your email takes less time than trying to guess if that was a capital P or lowercase p in "p455w0rD".

Re:Do not use standard passwords

[ShanghaiBill]

Salting doesn't stop brute force crackers like JtR

Salting doesn't make brute force crackers impossible, but it makes brute force much, much less effective. If I have two million unsalted passwords, I just need to compute a hash for a dictionary word one time and then do two million string comparisons. If I have two million salted passwords, then I need to hash the dictionary word two million times. That is far, far more time consuming.

Re:Do not use standard passwords

[Bengie]

But instead of 4 hours to crack 2mil hashes, he would have spent 4 hours per hash for 2mil hashes. It makes a small difference.

Re:Do not use standard passwords

[zzsmirkzz]

f I have two million salted passwords, then I need to hash the dictionary word two million times.

And if the salts were different on every password were secured separately from the password list, you'd have to try and deduce the salt first, two million times.

Re:Do not use standard passwords

[blueg3]

Salting doesn't stop brute force crackers like JtR, it only stops attackers from using a rainbow table and/or discovering that two people have the same password.

Both of those latter things are significant risks. However, it also substantially slows down brute-force crackers when applied to large password lists.

If you apply a brute-force cracker to a list of, say, a million unsalted password hashes, then you need to only compute the hash of each potential password once and compare the result against all million hashes. With a reasonably good in-memory storage system for the hashes, nearly 100% of your time is spent computing hashes (and not in comparison or password generation). So, with unsalted passwords, cracking a million passwords is as fast as cracking one (but much more lucrative).

With salted passwords, you need to compute the hash of each potential password for each entry in the hash list (since they all, ostensibly, have different salts). So you need to compute a million hashes in order to check one possible password (for the whole list). That is a substantial slowdown. With salted passwords, you are essentially cracking every password in a list separately -- having a large list gives you zero speed benefits.

If a factor of a million slowdown doesn't seem like much, consider that many good password-based encryption system use key strengthening, where the password (and salt) are passed through many chained rounds of hashing. Roughly a million, on modern processors. The whole purpose of this is to slow down brute-force password cracking by increasing the cost of a guess. It's enough of a change that instead of being able to get through a very large keyspace in a reasonable time (with only one hash round), you're stuck only being able to crack very bad passwords (with a million hash rounds). That's a very significant difference.

Re:Do not use standard passwords

[Culture20]

Chances are if someone has access to the password file, they also have access to the program files (maybe even the source code). This of course excludes anyone the first someone distributes the pw file to.

Re:Do not use standard passwords

[RenderSeven]

What an excellent opportunity! I just told everybody on my LinkedIn account what I *really* thought of them, waited an hour, and told them all my password was hacked. Good times, good times.

Re:Do not use standard passwords

[Windows Breaker G4]

https://www.grc.com/haystack.htm this is worth reading and makes some interesting points that it has more to do with length than randomness for bruteforce protection (unless you make it like passwordabc123)

Re:Do not use standard passwords

[Bengie]

One does have to add that the password would have to be focused on, which doesn't happen with database dumps like these, and it would cost a pretty penny. 10 char password with mixed/etc would take on average 1 year when doing 1 tril checks/sec. To break within an hour, one would need access to ~80-800 peta-flops of compute. Definitely something someone targeting a password could do, but it isn't cheap.

Re:Do not use standard passwords

[Anonymous Coward]

All those "crackable in n seconds" guestimates are based on the password being hashed in a fast hash algorithm exactly one time. That's why you can make hundreds of millions of guesses a second. If you simply iterate the hashed a 100,000 times, you make it 100,000 times harder to crack.

Re:Do not use standard passwords

[Junta]

If you have a salt in *code* (I presume a static one), I would wager it would be easy to discern. A salt is not supposed to be 'secret', it's just supposed to prevent easy identification of common passwords and a simplistic rainbow table attack.

Now if each client had a machine generated salt to append before transmit to server, that actually is servicable. Of course, the standard practice of complete obfuscation of the password through local algorithms is better.

Re:Do not use standard passwords

[hoggoth]

Yeah, me too. I told my brother that stealing my girlfriend in the 8th grade was a shitty thing to do and he should stop getting drunk in bars. Then an hour later I told him my account was hacked and that wasn't me who wrote that.

Re:Do not use standard passwords

[PReDiToR]

Have you ever heard of Password Hasher?
Mine defaults to even for sites that I'll never visit again I have as standard 26 character upper, lower and symbol passwords that I don't have to remember. All I need to know is the passphrase, something like "0nLy 1 Know Thi$ pA$$phrase!" or "mmm pizza". Makes no odds, you still get a 26 char PW that has Ul$ in it.

I know a lot of people don't use Firefox, but this really is a killer extension.

Re:Do not use standard passwords

[Anonymous Coward]

Jesus, people ... salt your hash. Hell, split the password and put a dynamic salt in the middle.

Re:Do not use standard passwords

[moderatorrater]

if the salts were different on every password

If it's not then it's not really a salt.

if the salts...were secured separately from the password list

That's not really feasible. Presumably if they have access to the passwords they also have access to the salts. In the end the legitimate application requires access to both, so if they've compromised the application they can probably get both.

Re:Do not use standard passwords

[RenderSeven]

Apparently your account was hacked by your 8th grade girlfriend working with the bartender (hey if you knew she was that tech-savvy you might have held onto her better)

Re:Do not use standard passwords

[Bert64]

Worse than that, without salts you can precompute the hashes (eg rainbow tables) and do subsequent attacks far more efficiently against anyone using the same hash type (and unsalted md5, sha-1 and ntlm are extremely common making it well worth the effort of generating tables)...
Tables can be (and often are) shared, thus distributing the required hashing power across a much larger pool of resources.

Re:Do not use standard passwords

[Kergan]

If the salt used is not part of your password's hash, you're doing it wrong. Salts should be unique per user, not site-wide.

Re:Do not use standard passwords

[zzsmirkzz]

That's not really feasible. Presumably if they have access to the passwords they also have access to the salts. In the end the legitimate application requires access to both, so if they've compromised the application they can probably get both.

It seems perfectly feasible to me.

1) A part of the salt is static and hidden in application code. This means even in the DB of salts is compromised, deduction of the missing piece is still required (as well as knowledge of its existence).

2) In a example setup there are three servers, the Application/Authentication server that is accepting login requests (Server A), the Database server hosting the DB of password hashes (Server B), and the Database server hosting the DB of the password salts (Server C).

3) The servers are configured so that Server A can communicate with the outside world and servers B and C. Server B can only communicate with Server A. Server C can only communicate with Server A.

In this setup the only server than can be remotely compromised is Server A which does not have direct access to either the list of hashes or the list of salts. In order to get this information an attacker would have to take control of Server A and query both databases, one record at-a-time. The search/index key in both databases would be the username, so the attacker would also need the complete list of usernames as well.

Now, I dreamed up this scenario in about 5-10 minutes. Please explain why it's unfeasible and assume security is high priority consideration.

Re:Do not use standard passwords

[Anonymous Coward]

Passwords are just *one* of the methods your account is safe. Important sites will limit you to a few guesses before locking down your account and/or will require 2 factor authentication before allowing to login from unknown computer. You know, those "secret questions" that are basically best treated as passwords.

What is the moral of the story is *never* use the same password on more than one website/service/whatever.

Re:Do not use standard passwords

[Anonymous Coward]

The author of grc.com obviously doesn't understand jack shit about password entropy.

Re:Do not use standard passwords

[Anonymous Coward]

Server A is external. Server A can talk to Server B. Server A can talk to Server C.

I compromise Server A. I can now talk to Server B. I can now talk to Server C.

Exactly how do you think this is "high security" rather than "slightly better, if obvious, tiered security".

Re:Do not use standard passwords

[SecurityTheatre]

trying to guess if that was a capital P or lowercase p in "p455w0rD".

As an aside, most capable crackers test for "leet" (7334) substitutions very early in their permutation rules. The word "password" is at the top of every dictionary file and is always included in the "top 100" password lists that crackers frequently expose to more detailed permutations.

This password is almost as weak as using a somewhat obscure dictionary word like "flagellate" or "dismember". (those words may or may not have been carefully chosen)

Re:Do not use standard passwords

[moderatorrater]

A part of the salt is static and hidden in application code. This means even in the DB of salts is compromised, deduction of the missing piece is still required (as well as knowledge of its existence)..

This is already common practice and has nothing to do with what you're talking about. I will therefore ignore it :D

In a example setup there are three servers, the Application/Authentication server that is accepting login requests (Server A), the Database server hosting the DB of password hashes (Server B), and the Database server hosting the DB of the password salts (Server C).

It all comes down to cost. Having a dedicated database that just holds either the hash or the salt is definitely more secure, but you're paying a lot of money for something that only really protects against SQL injections. If they've already compromised server A or if it's an internal leak, then they'll still have access to both databases.

If properly stored with a strong hashing algorithm, a salt, a static component in the code, and key stretching, then the strength of the resulting hash is entirely up to the user. If the user chooses to use a secure password, they'll be secure even in the event of a hash leak. If security is indeed a "high priority consideration", then they're probably going to use 2-factor authentication anyway. The gap where the cost is worth using separate databases but not using 2-factor is extremely small.

The search/index key in both databases would be the username, so the attacker would also need the complete list of usernames as well.

Actually, you'd want it to be the id on the user table so that no additional information is being leaked if they can only get the one table. Either way, I can't imagine any realistic scenario where the attacker gets only one column out of the table. 99.9% of the time they'll be able to get everything out of the table that they want, so the linking column would be leaked as well.

Re:Do not use standard passwords

[Anonymous Coward]

If only people actually checked their linkedin accounts after setting them up.

Re:Do not use standard passwords

[SilentStaid]

She clearly left him because of his lax security behavior, you insensitive clod.

Re:Do not use standard passwords

[Hadlock]

As an aside, that password was a joke. *woosh*

Re:Do not use standard passwords

[Anonymous Coward]

"I just need to compute a hash for a dictionary word one time and then do two million string comparisons."

If you presort the hashes, you can do a binary search on each computed hash in about a dozen string comparisons, not 2 million. Without salt, cracking millions of unsalted hashes takes only a little longer than cracking just one.

Re:Do not use standard passwords

[Wahakalaka]

Yes, that would require the attacker to have the salt generation algorithm (probably the code base), and would possibly mess up automated crackers like in TFA (I think?)

Re:Do not use standard passwords

[falzer]

What next? You use 15 or 20 character passwords, or a passphrase of several words.

But for the server side, use key strengthening with something like bcrypt or scrypt.
If it takes 1 second on very fast hardware to hash a single password, then your attacker has to also spend a lot of time on each hash attempt.
scrypt was also designed with custom hardware attacks in mind (it uses lots of memory) so it is still slow and expensive even if the attacker has key derivation logic in an asic or fpga.

If it takes a tenth of a second for an attacker to derive a key (or hash) from a password then a 10 character password is still incredibly strong.
If the passwords have salt (as they should) even a plain english dictionary attack on a 2M password file will take years to finish.

As faster hardware becomes available, you adapt by changing the key derivation parameters.

Re:Do not use standard passwords

[Moses48]

The salt I'm talking about is unique per user. The difference is the salt generating algorithm is in the code and not known.

Re:Do not use standard passwords

[slashmydots]

Speaking of that, and this is really bugging me, I had read they weren't salted. So...why hasn't anyone reversed every single hash up to 22 or 23 characters including symbols using a rainbow table and machine with 32GB of RAM? It's trivially easy to do. Why are they all wasting their time brute forcing it with dictionaries and crap? Is there something I'm missing that makes their particular hash list rainbow-proof?

Re:Do not use standard passwords

[doublebackslash]

do two million string comparisons

Naw man, not even that. You could use a trie and perform a single search across any number of strings in O(n) time relative to the length of the string with early bailout when the string you are attempting to match diverges from the set you are matching. You can even do some optimizations on your trie after it is built so that the leaves contain the unique "tails" of strings.

OR you could even use a hash table and do the lookup in amortized O(1) time

Very very fast indeed to match your gusses against a set of unsalted hashes

Re:Do not use standard passwords

[Anonymous Coward]

Modding this "redundant" was sheer genius..

Re:Do not use standard passwords

[sirlark]

Apart from not using a salt, what the hell were they doing using SHA1?

Re:Do not use standard passwords

[Anonymous Coward]

"prevent easy identification of common passwords and a simplistic rainbow table attack"

Yes it does that, but it's also largely simply to make the data to hash longer and therefore slow the computation down, making it take far longer harder to crack. A fairly short say 10 character hash is probably at least as long as the average password and therefore doubles the data length, which makes it take several orders of magnitude longer to brute force potentially increasing the time taken to crack a password from minutes/hours to centuries.

Re:Do not use standard passwords

[OdinOdin_]

How about the global part of the in-memory web application config:
  * Part of the salt that is global (the same for all passwords)
  * A XOR value to apply to the per-userId part of the salt
  * A symmetric key (for encrypting the data in the DB column)

Were all loaded at runtime when the application starts and held in memory only. This information would be loaded at runtime using bi-directional SSL certificate authentication with locked down IP addresses of a remote system holding this data. (the same principal can be applied to securing armoured private key parts of your regular SSL certificates allowing a sites https:/// to function)

The symmetric key is used to actually encrypt the data that is stored in SQL (so the salted hashes are stored in the DB encrypted using a symmetric key that the non-SQL server has present only in memory). This is to help thwart column/file/backup content reads from the SQL system should that occur via any compromised mechanism.

Your SQL server is then locked down so it will never allow a SELECT of the column and access is only possible via store procedure(s) which allows access one-at-a-time (as you suggest) but in order for the stored procedue to allow read back of the encrypted. Access to run the stored proc is restricted to this different SQL login account whose only function is to serve high-security parts.

Your SQL connection used for authentication and high-security parts of your web-app itself is SSL/TLS encrypted and the DB server mandates its use with a valid client certificate in order to allow access to the stored procedures. Alternatively another mechism is required for the SQL server to authenticate the client to allow read-back maybe some value also derived from knowing the correct password but extreme consideration over what is sent over the write needs to be made, better to just assure SSL/TLS is used for SQL connection.

The password hash itself would use PBKDF2 the only reasonable choice surely.

Add into this that your web server uses signed code (like signed Java bytecode) and a VM based language to help avoid buffer exploits of the webserver/application code itself.

That must further restict quite a few attack vectors and the main (expensive) hosting setup can be a regular 2 host setup. Maybe the 3rd system in the mix would be an enterprise grade raspberry-pi that provides this service and console access only.

Re:Do not use standard passwords

[Roger Lindsjo]

Every single hash of 22 characters including symbols are probably more than you expect. Just using upper and lower case and digits in combinations of length 1-22 would give you 2752193871537130242917970742712955267306 combinations. That's quite a few to store.

Re:Do not use standard passwords

[Anonymous Coward]

A 22 char long rainbow table is not trivially easy to do.

The largest md5 rainbow table I know of is:
md5_mixalpha-numeric-all-space#1-8: 1049 GB

which covers approximately 99.9% of all passwords up to 8 characters in length (you can get it at http://www.freerainbowtables.com/en/tables2/).

There are actual reverse lookup tables out there on the internet that have 10^10 entries or so. If they contained all entries from the 95 character space with as few characters as possible then they would only have up to 5 character passwords.

Re:Do not use standard passwords

[moderatorrater]

Well played, sir, well played.

• Part of the salt that is global (the same for all passwords)

• A XOR value to apply to the per-userId part of the salt

• A symmetric key (for encrypting the data in the DB column)

Each of these is essentially serving the same purpose from what I can tell. The point of having a portion in the code that is the same for all passwords and one that's in the database on a per-user basis is so that they have to have access to both the database and the code. Each of these is just another piece that requires a bit more than what's in the database. In other words, from a cryptographic standpoint, they're all equivalent to a static portion since they all serve to be a required piece of knowledge to compute the hash. Putting it in different secure places adds incremental security, but in the end they'll all be accessible to the application so they're all at the same level of security.

Your SQL server is then locked down so it will never allow a SELECT of the column and access is only possible via store procedure(s) which allows access one-at-a-time (as you suggest) but in order for the stored procedue to allow read back of the encrypted. Access to run the stored proc is restricted to this different SQL login account whose only function is to serve high-security parts.

Basic least privilege, but implemented very well. I like it.

The password hash itself would use PBKDF2 the only reasonable choice surely.

At it's best PBKDF2 is the same as what I described above: one of the sha-2 family of hashes, key stretching, and good salting. The down side is that PBKDF2 is also obfuscating what's going on and allows an insecure mode of use. I much prefer to use the raw hash algorithms so I can be sure what's going on and that I'm using it right, but it's pretty much even either way.

Re:Do not use standard passwords

[Anonymous Coward]

Are you the result of a Mensa genetic engineering experiment

or vagina

Re:Do not use standard passwords

[slew]

Salt: a random per user number (not an algorithm) used to foil attacks like rainbow tables.
Signature: an algorithm that authenticates a message (like a password).

Typically any secret algorithm is considered security by obfuscation.

So a "salt" generating algorithm would be an obfuscated pseudo-random number generator used in a non-standard way as non-cryptographically secure signature. Yeah, that's the ticket to good security ;^)

Re:Do not use standard passwords

[drinkypoo]

[citation needed] the passwords are typically stored in a database, which typically has a separate password from the file repository where the program files are stored, which in the case of a binary-compiled site, typically has a separate password from the separate repository where the code is stored.

Re:Do not use standard passwords

[Anonymous Coward]

...and query both databases, one record at-a-time. The search/index key in both databases would be the username...

Uhm, forgive me if this seems like a silly question, but... Why would the attacker have to query each record individually?

Re:Do not use standard passwords

[viperidaenz]

Just because someone came out of a Mensa vagina doesn't make them smart. Doesn't even make them related to the owner of said vagina. Who know how many men (or women) have been in there

Re:Do not use standard passwords

[cheater512]

If you get access to the website files, the website files will be able to connect to the db.
Most sites aren't compiled binaries.

Re:Do not use standard passwords

[kwark]

If you keep the salt secret, the client is required to send a plaintext password to the server to have it hashed. If the salt is public (sent to the client), the client can do the hashing locally and avoid ever sending the plaintext password to the server (which might be compromized). So my guess for a fairly secure login/authentication scheme (IANACE):

client: Hi I'm foo@bar, give me a nonce and my salt.
server: Here is you nonce with a salt.
client: sents hash(hash(secret+salt)+nonce)
server: compares hash(hash(secret+salt)+nonce)==hash(DB[user][passwd]+nonce)

It keeps the password secret even from the server, the nonce prevents replay attacks. Login could even be done over an unencrypted connection. Could be wrapped with another nonce to prevent sending foo@bar as plaintext.

The weakest point is sending the newly created saltedhash to the server at account creation as the saltedhash is essentially the password. Add a little PKI to increase safety.

Re:Do not use standard passwords

[drinkypoo]

While both of those statements are fairly true (access can be protected by means other than l/p) all of mine are true as well. Having the db doesn't necessarily mean you have the fs.

Re:Do not use standard passwords

[viperidaenz]

Your three "in memory only" secrets are never stored on disk and input by a user every time the application starts then? I'd hate to be the person who has to memorize all that.

Re:Do not use standard passwords

[lattyware]

What you are describing is more akin to a pepper - a single value stored code-side that is appended to all data (the idea being if only the database is compromised (SQL injection, for example), your passwords are incredibly long and virtually impossible to brute-force in the foreseable future.

Salts, on the other hand, want to be an individual value for each password, stored in the database. This means that if someone is brute forcing your database, it becomes a magnitude harder. Not only does it stop rainbow tables, but it also stops the attacker using one attack against the entire database. A single salt stops rainbow tables, but you can brute force the entire database at once (generate a value with salt, check against every hash in database, repeat) - as opposed to having to brute force each record individually - making it a significantly larger effort.

Re:Do not use standard passwords

[zzsmirkzz]

Uhm, forgive me if this seems like a silly question, but... Why would the attacker have to query each record individually?

Because the databases are remote (from Server A) and the DB servers are locked down and will only allow one record queries.

Re:Do not use standard passwords

[atamido]

The salt I'm talking about is unique per user. The difference is the salt generating algorithm is in the code and not known.

Start with the username, have a long fixed salt value in the code, and then add the password. That ensures that the hacker must also gain access to the code, decipher the hashing method, and be able to isolate the fixed salt value. If you had a single hardened system that only took the password as input, read the database, and then responded with a true/false then I imagine that retrieving the tiny bit of authentication code would be rather difficult.

That said, there are a number of hardware cards designed specifically to not be able to reveal the private key. I imagine it would be trivial to have one that took two values (username + password), inserted the salt between then, perform a common SHA-1 hash, and spit it out. You'd need to have one physically attached to any system actually performing authentication, but it'd be pretty much unbreakable right now with a salt at least 128-bits in size. Use SHA-512 plus a 512 bit hash and gain a few decades.

Re:Do not use standard passwords

[OdinOdin_]

No the respberry-pi device is the 3rd server that provides the hardware secured device to contain the secrets.

This device:
  * Might only have a console for maintenance (you needed physical access to create/overwrite secrets).
  * Would lock down clients using SSL/TLS peer certificate authentication as well as IP based access control. So only the correct IP can ask for the data and that correct IP must have a valid private PKI exchange to validate itself as genuine.
  * Might not hand out the data immediately when asked, it might for example open a dialog to a system administrators mobile phone which acts as an alert that require acknowledgement before the secrets are handed to any system.
  * Raspberry-pi might support TPM so might have signed boot loader, signed kernel, signed userspace, making the hardware it more tamper proof. A seemingly easier thing to do on an embedded device.
  * The device might run linux and all of 2 other processes with no normal userspace again making it difficult to exploit.
  * The device would internally log things.

Contrast this with a notion of a 2nd full SQL system that gets rather expensive to maintain compared to a 30 EUR R-pi box.

Re:Do not use standard passwords

[OdinOdin_]

You are correct that the 2 parts to the salt serve the same purpose. But there isn't much to be gained or lost from using a larger salt (when we're probably talking about going from 64bit to 128bits) if we presume the values are 64bit each. The userId is something the attacker will know so it can't be used as-is directly as that makes it no more secure than having the salt as the first part of the output string stored in the DB (like /etc/passwd and maybe /etc/shadow does on unix).

But the symmetric key is to encrypt the results of the salted hash and serves a different purpose to armour the data the attacker might be able to lift via any mechanism. This is the same principal that GPG/PGP will armor your private key part with encryption.

This ensures that at all times the salted-hash is conveyed around, is backed up, is stored on disk, it is in an encrypted form that and the decryption key is not stored in the same domain. (it is not in the backup data set as data or code, it is not stored as part of the SQL config if you were using SQL server assisted column encrytion). It is not converyed over TCP with SQL client/server communication to perform data UPDATEs or SELECTs.

In all this makes only one place where all the required data is known in plain text form, that is in the web application where the inbound data from the HTTP client was secured with HTTPS, the SQL data secured with a symmetric key (as well as optionally SSL).

So now you are left with the problem of making sure the host has a clean user-space but things like TPM / SElinux and using VM based network accessible applications.

What are you saying the problem with PBKDF2 is ? is it possible to loose bits of information between input and output (like a truncated input). If anything I would think that PBKDF2 would be the best "key stretcher" there is and it already has the notion of number of rounds that you can adjust to suit your performance/security requirements. Your forum might use 64 rounds and you banking application might use 4096 rounds.

If you store the number of rounds used as part of the symmetric encryted result it is actually possible to seamlessly upgrade everyones number of rounds over time as they login and use the service. i.e. you deploy your application in 2008 and you setup for 2000 rounds and this was good. 1 million users signed up and used the service. Now it is 2012 and you change your policy and configure for 4000 rounds. Now as each user logs in it can validate their stored password against the 2000 rounds ok, but then because it has the password it can upgrade it to the 4000 round versions and overwrite the data in SQL. Any accounts not signed in for 6 months would be auto-locked.

PBKDF2 can also be setup to use whichever hash and HMAC you prefer so again this can be upgradeded in the same way so you deploy in 2008 with SHA1 and in 2012 you choose SHA256.

Personally I think that one of the web browser initiaves for always storing your password credentials locally at the client and having a mechanism that HTTP form login can make use of to login is better. This should be PKI based so there is no authentication data of value to be compromised at the 1000s of website you signup to. It is much better for both user and website operator to put the onus back onto the client to keeping their credentials secure.

Re:Do not use standard passwords

[Moses48]

You are correct Slew. It is less "cryptographically secure." And I did break the golden rule of cryptography "Don't roll your own."

Yet, the idea behind what I stated still makes sense. Security through obscurity shouldn't be thrown out just because it's trivial once you know it. Ideally you would just use a traditional salt and store it some place "obscure". (ie: not your db, or store it AES encoded in the DB with the key in the code). You arn't inventing anything new, but you are making them know more than find a tool online that knows how to crack passwords given a salt. They would need to decompile your code for the AES key.

Re:Do not use standard passwords

[Anonymous Coward]

What next? How about protecting your password hash file from being stolen in the first place? Why do we assume this is inevitable? Maybe because our baseline security is crap, and we try to cover for this by palming off the burden on the end user. An established strategy, but not a particularly good one.

Re:Do not use standard passwords

[viperidaenz]

The price tag for the hardware is irrelevant when you take into account the time spent building and supporting the software that runs on it. The 100 hours it may take someone to build your custom linux distribution, the 1000's it will cost to manufacture custom TPM hardware because your 30EUR Raspberry-pi doesn't have a TPM, the many 100's of hours you'll have to spending testing it... You may as well have spent $20,000 some pre-existing solution...it'll be a fraction of the cost. I personally just spent a day writing a few classes and some diagrams, I billed around $800 for that. The software I'm working on is not as complex as what you're trying to describe yet I'll be charging $800 a day for 6 months. Add some HR overhead on to that, some more $/hr that goes to the consulting company that got me the position and you're looking at $200,000. I'm only one member of a team of seven.

Aside from the "might ask a sysadmin to approve the request", a compromise of the system that talks to the secret holding device makes the TLS, TPM, IP controls, internal logging and hardened linux build irrelevant too since you have access to its private certificates and ip address. The only thing you're stopping is another compromised system on the network gaining access.

Re:Do not use standard passwords

[OdinOdin_]

Your costs are obviously way more expensive than mine maybe this is beurocracy. But in all commercial projects I have worked on costs have always been a major consideration over the methods being used. The thread did talk of costs for small scale hosting being an issue to do this kind of thing right. It is obviously possible to spend an infinite amount of money on anything so what is more interesting is how little you can spend to achieve how much.

When open source is being used the costs of software/maintenance only needs to be spent by a small part of the community. The rest can get the benefits for just an hours work to install and setup much like CentOS achieves.

I am claiming that for $100 you can have the hardware and software for this box setup and turnkey to use that comodatized most of the features of a $200,000 solution. Maybe you don't agree with this possibility.

Over the TPM just using ARM CPU SoC that supports write once memory so the boot loader is locked with a signed trust chain. Yes this would exclude the Raspberry-pi but the idea of taking the R-pi design and simply asking a manufacturer to not to install firmware in the same way should do the trick. We want the R-pi design, we want to pay $10 more but we want you to do one less thing during manufacture, no brainer for supplier.

Of course any compromise to the system is a problem. However in a previous reply it has already been explained that:
  * You might like to consider using a VM based language and signed bytecode on such a system. As well as SElinux and other such OS things, so for the paranoid then lock firewall rules down to a specific process.
  * The box with the key might not just reply to every request to retrieve the key in realtime. It might for example require 2 factor authorization to emit the data, such as a pager/sms/call to a human engineer to authorize the system. This would work much like UAC prompt where the engineer would need to know / expect there to be a reload of this key data to be happening.
The whole security thing is just layers of protection and hopefully the attacker will set off a tripwire along the way before they manage to get everything in place to compete the compromise.

Re:Do not use standard passwords

[viperidaenz]

My costs come from working in the banking and government sectors.

We want the R-pi design, we want to pay $10 more but we want you to do one less thing during manufacture, no brainer for supplier.

Yes, it is definitely a no brainer. The only reason it costs $35 is because they do runs of 10,000 identical units at a time. That $35 cost is also marginal profit, since its being run by a charity organisation. The SOC used has the capability to write to its flash memory where the boot loader is located. This loads the OS from an SD card. Good luck getting information about locking down that bootloader without signing NDA's with broadcom. I doubt that will come for free.

A ball-park figure for running a custom board based off the raspberry pi with some flash memory instead of SD and manufacturing it in one off quantities is probably in the order of $1000 or more. a single 4 layer board isn't cheap. a single run loading the smd components isn't cheap either. These are processes that require expensive tooling costs and are only economical when doing runs in the 1000's.

YAY the cracked the passwords

[Anonymous Coward]

They still dont have any account bound to them... so its like owning 2M keys to very specific doors witch resides somewhere in a city of the size of new york. Totaly useless.

Re:YAY the cracked the passwords

[TooMuchToDo]

Unless you can derive the username from the password. But heh, what are the odds of that happening? *rolls eyes*

Re:YAY the cracked the passwords

[EasyTarget]

... It is only useless if you have a criminal intent.

For those of us who do not actually want to abuse this leak, but instead learn from it, this is a great source of data!
It shows just how *****ingly clueless most people are when it comes to creating a password.
It shows how getting a bit smarter makes your password harder to crack, but still vulnerable to dictionary+statistical attacks.
It shows how 100% random is probably the way to go for anything of value.

Re:YAY the cracked the passwords

[Anonymous Coward]

Unless you can derive the username from the password. But heh, what are the odds of that happening? *rolls eyes*

I'm pretty sure that the username for John123 is John.

Re:YAY the cracked the passwords

[brix]

Who is "they"? The public at large has access to the password file but not the account names. However, there's really no telling what the original hacker has. For security purposes, we assume the worst, and that is that someone has both the account names and a password file for which almost a third of the passwords have proven easily cracked.

Re:YAY the cracked the passwords

[kuiken]

Except the guy who released the hashes most probably does have the usernames as well.

Re:YAY the cracked the passwords

[Anonymous Coward]

If I can get your 6.5 million hashed passwords, I can probably get to your userID's. Just because the original leaker didn't post the userID's, doesn't mean they don't have them.

Oh, CAPTCHA = "steals", gotta love that.

Re:YAY the cracked the passwords

[drunkennewfiemidget]

... as far as you know.

Just because they only leaked the password doesn't mean they don't have the usernames that go with them, intend on cracking the passwords, and then just looking up the matching hashes somewhere else to link accounts to passwords.

Re:YAY the cracked the passwords

[Lisandro]

You don't have the account names bounded to each password. There's a pretty good chance whoever got that information has both pieces of the list.

Re:YAY the cracked the passwords

[DarkOx]

Somewhere a relation of password hashes to user names must be stored so that the system can check passwords; so the information exists. I think we have to assume who ever it was who crack the site in the first place has that information. They simply opted not to make it public for any number of reasons (few good for anyone with an account).

So its more like they have 2M keys, to specific houses and are jingling them in front of you just to prove it.

gpg

[Anonymous Coward]

gpg - --gen-rand 1 9 | gpg -cat > linkedin.asc

And presto, 72 bits of sweet entropy in your password which you don't even need to remember. It suffices to remember ONE password.
Need your linkedin password?
gpg linkedin.asc | xsel
(and type your one password).

Note that this way your linkedin password is never typed and never shows up on the screen.

Re:gpg

[hattig]

Nice - is there a browser extension that can automate this based upon the current website/url/form?

Re:gpg

[tuffy]

I've tried a similar one-password principle using HMAC digests:

python -c "from hashlib import sha1; from hmac import HMAC; from getpass import getpass; print HMAC('site.com', getpass(), sha1).digest().encode('base64')"

By simply remembering the site name and a strong master password, one can generate a unique password for each site.

Re:gpg

[Terrasque]

http://hashapass.com/ have a bookmarklet. Not completely auto, you still need to write in a keyword for the site, but still.. Does a good job.

Re:gpg

[sl3xd]

A similar (commercial) concept is available on Windows, Mac, iOS, and Android: 1Password. Browser plugins are included, and it works quite well.

Sadly, there is no LInux/BSD version - but there is a browser-based '1passwordanywhere' that makes it possible to use it with any web browser - I'm not sure exactly, but I'd wager it's javascript kept in the password database.

The datastore is supposedly fully-documented - nobody has written a native Linux client yet, but one can hope...

Re:gpg

[Anonymous Coward]

What's wrong with the Firefox password manager? It's semi-automatic per site (you need to click the "login" equivalent on the site) and you can fill it with however hard pws you want as long as the site supports it.

Backup your profile and that's it.

If you desperately want to use gpg without any copypasta the source for the password manager is meant to be open so have fun :)

Re:gpg

[Anonymous Coward]

Personally, I use Password Maker, pretty simplistic and has browser/iPhone apps. The only issue if you do this is when you log into the presentation machine in your office and can't remember your password for your ticketing system during backlog grooming... But, there's always the web-based javascript version you can use :)

Lessons learned?

[Anonymous Coward]

That would be a new one.

Value of a linkedin account

[vlm]

What is the value of a random persons stolen linkedin account... I'm trying to figure out how its not zero. I have a pretty devious mind but I can't think of any way to make money off this with a reasonable chance of success. If you poison enough of the well, the whole data set becomes worthless so you can't threaten to modify data. Maybe they tried to extort money from linkedin inc and failed so they released purely by spite? Post IPO = the titanic has been struck by the iceberg and you've already gotten away, so it doesn't matter how fast the ship sinks, therefore no point in paying extortion fees?

Assuming only a fraction of accounts have been stolen and not the entire user list.... Why do people assume its only a tiny fraction and not the whole list of users? The same people who don't understand the concept of a "salt" must surely be correct when they say only a couple million records are out there. I would assume based on their heroic security performance to date, that ALL records are out there, we just only know about a couple.

Re:Value of a linkedin account

[Anonymous Coward]

It probably has little value, but the account name is an email address. Many people use the same account/pass combination for multiple sites, including perchance their paypal account. If they manage to pull a few million email/password combos from linkedin, I can guarantee you that some of those combinations will match paypal exactly.

Re:Value of a linkedin account

[Anonymous Coward]

Verified E-mails are supposedly worth money to spammers, especially with a list of trusted e-mail addresses. Then there are all the crossover passwords, so maybe access to 50% of the actual email accounts, and in terms of identity theft, you can get pretty far with just access to an e-mail account.

Re:Value of a linkedin account

[Anonymous Coward]

What is the value of a random persons stolen linkedin account... I'm trying to figure out how its not zero. I have a pretty devious mind but I can't think of any way to make money off this with a reasonable chance of success.

You're right, using the stolen credential on LinkedIn is pretty much useless. But with 2,000,000 for sure cracked passwords, a bad guy would now have 2,000,000 sets of login credentials try elsewhere. How about amazon.com? Or paypal? How many of those 2 million logins are reused? Even if it were only 1%, that'd still be 20,000 sets of logins for paypal accounts. And there's plenty of money in that.

Disclaimer: I would never do such a thing myself. I've more been on the receiving/victim end of that thought process. Needless to say, I don't reuse passwords anymore.

Re:Value of a linkedin account

[Anonymous Coward]

Instead of faking facebook accounts, someone could steal a real linkedin account to do the same:

How spies used Facebook to steal Nato chiefs’ details

NATO'S most senior commander was at the centre of a major security alert when a series of his colleagues fell for a fake Facebook account opened in his name - apparently by Chinese spies.

http://www.telegraph.co.uk/technology/9136029/How-spies-used-Facebook-to-steal-Nato-chiefs-details.html

Re:Value of a linkedin account

[Fnord666]

What is the value of a random persons stolen linkedin account... I'm trying to figure out how its not zero.

Because people have been known to reuse passwords on other sites that might have a non-zero value.

Re:Value of a linkedin account

[llZENll]

A very easy way to profit is to release the stolen account data waiting for the negative press to push the stock down.

Re:Value of a linkedin account

[Anonymous Coward]

How about sending out phishing e-mails to people's contacts with links that could include drive by downloads?

Despite all the news about the LinkedIn hack, people still trust their friends. If someone post a news article in their feed or sends a private message with a link to bit.ly or something, a lot of people will click it.

Re:Value of a linkedin account

[Kergan]

What is the value of a random persons stolen linkedin account... I'm trying to figure out how its not zero. I have a pretty devious mind but I can't think of any way to make money off this with a reasonable chance of success.

Many people, especially younger people, have a unique weak password. So if you've their login and their password, chances are you can also access their Facebook account, their paypal account, their bank account, etc.

Re:Value of a linkedin account

[trdrstv]

What is the value of a random persons stolen linkedin account... I'm trying to figure out how its not zero. I have a pretty devious mind but I can't think of any way to make money off this with a reasonable chance of success.

I'm trying to figure out the value of an active LinkedIn account. Seriously, does anyone know of anybody who got hired thanks to linkedin ?

Re:Value of a linkedin account

[rhsanborn]

And even if it doesn't match their paypall login, it may match their email login, from which, you can reset many passwords.

Re:Value of a linkedin account

[Kyrene]

Me. In fact at least 90% of the people who contact me for interviews are all via LinkedIn. I don't even bother applying anywhere else. It may matter that I'm a software engineer, senior/lead level, and do .NET development, so YMMV.

Re:Value of a linkedin account

[Anonymous Coward]

maybe by shorting the stock?

Re:Value of a linkedin account

[icebrain]

I've been cold-called by several recruiters via Linkedin, but none from any other site, or by any other means. A couple of them were good offers at well-known companies, but they required that I move further north and/or west than I care to (anywhere it snows more than once every few years is out, as is anywhere west of Texas due to family location). If only there were more jobs in my field in warm, sunny Florida...

Re:Value of a linkedin account

[Anonymous Coward]

You can send in-mail to others who might assume you are the CEO of Bank of America and try to get them to act on your behalf, such as hire a guy into I.T.

Did he crack any random passphrases?

[khendron]

Like "correct horse battery staple"?

Re:Did he crack any random passphrases?

[Anonymous Coward]

Like "correct horse battery staple"?

I believe "correct horse battery staple" was the first passphrase they cracked.

The second was "khendron beats dead meme."

Re:Did he crack any random passphrases?

[Anonymous Coward]

"ObjectsLookLargerInTheMirror"
"OrWithoutZHair"

Re:Did he crack any random passphrases?

[MetricT]

I've been running them through my own cracker (doing so helps me to find new patterns I can use to audit our passwords at work). Almost 3 million cracked so far. No "correct horse battery staple", but getting there.

I'd still go with at least a 10 character computer-generated random password with a mix of all character types.

Length Password
40 1234567890123456789012345678901234567890
24 sociological imagination
24 linkedinlinkedinlinkedin
23 newlinkedinpassword1234
22 harekrishnaharekrishna

Re:Did he crack any random passphrases?

[Ginger Unicorn]

that's the same combination i have on my luggage!

Re:Did he crack any random passphrases?

[kasperd]

Like "correct horse battery staple"?

That one is not in the file. However CorrectHorseBatteryStaple hashes to a9cb82349d8c4f9aa4ba3210fadde81049300d0b, which is in the leaked list of hashes. That means either:

• The leak happened after 936
• The hackers put it in there as a prank
• This is actually the password for Randal Munroe's linkedin profile

And if the hypothesis about the first five characters in the file having been overwritten on those entries that were cracked already is true, this means this one was not cracked until now.

Re:Did he crack any random passphrases?

[Anonymous Coward]

It is also possible that someone has a password with a hash identical to this one (it should be possible).

Real lesson -- make guessing expensive!

[redelm]

The predictable whining (and obligatory xkcd rebut) will be to make passwds "stronger", because open hashes or fast guessing is acceptable provider security.

I call BS! More "blaming the victim". Any secadmin/netadmin who has hashes available or allows unthrottled passwd guessing is INCOMPETANT. Staff are paid for professional-level knowledge so users do not need to be concerned.

The work itself is very nice, MD5 hashes can be cracked quickly in massive parallel on GPU hardware. This only matters after the hashes have already been stolen.

Practical security should be more systemic -- the cost of a wrong guess is more than a nanosecond of GPU. There are at least network delays, and in many cases lockouts. The latter make random guessing too costly/slow, especially progressive systems that allow 5 wrongs immediately, 10 in an hour, 20 in a day, and lock hard (manual intervention) above that.

My father had one of the early ATM cards but had me operate the machinery. It had an 8 digit assigned PIN, but dropped quickly to 4 when it was realized the 8 were hard to remember, and swallowing the card after 3 wrong guesses was more than adequate.

Re:Real lesson -- make guessing expensive!

[slimjim8094]

What the hell are you talking about?? The problem wasn't the hashing - SHA1 is perfectly strong - it was the lack of salting, which makes attacks like this one possible. And "unthrottled passwd guessing" might be "incompetant" but preventing it doesn't do you a lick of good if you're testing against a list you downloaded.

Yeah, they screwed up. They shouldn't have allowed the password hashes to be compromised, and they should've salted the hashes so they would be essentially worthless if compromised, but that doesn't negate the value of a strong password.

Re:Real lesson -- make guessing expensive!

[Anonymous Coward]

I call BS! More "blaming the victim".

This is Slashdot. Haven't you figured out that blaming the victim, in pretty much all situations, is fashionable here? You're just going to get a lot of blank stares.

Re:Real lesson -- make guessing expensive!

[Anonymous Coward]

>INCOMPETANT
You don't say.

Re:Real lesson -- make guessing expensive!

[Lisandro]

While the issue was clearly not the hash algorithm here, it should be noted that SHA-1 is now effectively broken - you can get collisions in less time than using brute force.

It's still a perfectly usable hash algorithm, but it has been slowly phased out for SHA-2 (SHA-512) for some time now.

Re:Real lesson -- make guessing expensive!

[14erCleaner]

Locking an account after 20 wrong guesses enables a simple denial-of-service attack by your enemies.
And you mispeled "incompetant".

Re:Real lesson -- make guessing expensive!

[Anonymous Coward]

incompetent

see also...

irony and possibly... usability

Re:Real lesson -- make guessing expensive!

[slimjim8094]

Well, yes... I was being hyperbolic about SHA-1. The reason JtR is making headway is because the hashes are unsalted, not because the hash has problems. But if I understand it, doesn't salting even help with a weak hash? Given the hash of the password, you can perhaps find a colliding cleartext (is that the name for the input string?) in faster-than-bruteforce time but if you don't know the salt it doesn't help you because you can't completely control the input.

Re:Real lesson -- make guessing expensive!

[Rich0]

While SHA1 is broken, I doubt it makes much difference here.

Per your link, you can find collisions in SHA1 with 2^69 hash operations per password.

The people doing the cracking here did CONSIDERABLY fewer operations per password than this.

Sure, everybody should be moving on, but the fundamental issue here is that passwords that people can remember generally don't have enough entropy.

Re:Real lesson -- make guessing expensive!

[redelm]

As another reply commented, SHA1 is not "perfectly strong". And yes, salting is an easy assist to hash security. And yes, strong passwords have value, the problem is the human cost. Don't you evaluate user costs?

Unprofessionalism (in IT and elsewhere) transfers costs from the incompetent to users/customers. Of course some costs have to be transferred. But they have a cost-benefit including user costs. Even competent management [rare] will have trouble catching mistransfers because the diffuse user community is "each only slightly inconvenienced" and may not complain (inertia hurdle). Yet in aggregate, the loss is substantial.

Re:Real lesson -- make guessing expensive!

[kokako]

I agree that coming at this problem from the side of the user is not only blaming the victim but is ineffective. However, to understand why this is so I think that we need to consider human psychology. Why is that most people continue to use weak passwords, even though all but the lowest of the "low information" users understand the supposed importance of internet security? I assume that it is because they or their circle have not been victims of online identity theft. Until that happens to them, they will continue to use the weak passwords. Why bother with something complicated like a complex and difficult-to-remember password string when there don't seem to be any consequences? If online identity theft with significant monetary or professional consequences becomes sufficiently widespread, you will find that people will suddenly become interested in online security. At that point, however, I am sure that users will clamor for improved security measures on the corporate/server side. At that point, something like a security code of conduct might be appropriate. Corporations would clearly declare that they were following X security practices or adhering to Y set of standards for online security. Getting Joe123 to change his password from password123 to 8}0_(|5-'23a1_E_2_-! is not going to happen.

Re:Real lesson -- make guessing expensive!

[heypete]

Yes, but modern GPUs can compute SHA-1 hashes of various passwords at enormously fast rates. Even if they used per-user salts, it's likely that they would also be acquired during the original compromise: with the salts being known, the attacker could run through the various password possibilities at a high rate of speed.

Using just a plain hashing algorithm, even one like SHA-512, for password security is a bad idea as those hashes are designed (in part) for speed. Using something like PBKDF2 with a high number of iterations would help slow down brute-force attacking. If your system automatically increased the number of iterations over time to keep up with modern hardware, then that would help dramatically.

Something like bcrypt or scrypt could provide similar functionality but also require that the attacker have even more memory in addition to processing power.

Re:Real lesson -- make guessing expensive!

[PhrostyMcByte]

SHA-1, like MD5, is broken for digital signatures. When someone finds a way to reverse a hash back into a password, then it will be broken for passwords.

The only real argument against SHA-1 for passwords is that you can brute-force them rather quickly, but SHA-2 has the same problem. If this is an issue for you, use PBKDF2 or some similar algorithm.

Re:Real lesson -- make guessing expensive!

[0123456]

Yes, but modern GPUs can compute SHA-1 hashes of various passwords at enormously fast rates. Even if they used per-user salts, it's likely that they would also be acquired during the original compromise: with the salts being known, the attacker could run through the various password possibilities at a high rate of speed.

Yeah, just TWO MILLION times slower.

Re:Real lesson -- make guessing expensive!

[Bengie]

You just mixed a lot of online and offline ideas together. You can't throttle offline cracking, unless you ask the cracker "pretty please with sugar on top".

I haven't heard much of online cracking being an issue because of what you said; one simply can't effectively attempt many passwords without causing a DoS.

"The work itself is very nice, MD5 hashes can be cracked quickly in massive parallel on GPU hardware. This only matters after the hashes have already been stolen." This part is true.

Locking down accounts sounds great until you think of what would happen. Take gmail. Some large bot owner decides to make 20 attempts on every account. Soon no one in the world can access their gmail because their accounts are constantly locked. How long until Google decides to remove account locking on failed attempts?

Some people have mentioned 2 factor auth. One could also filter by location when deciding to block attempts. They could also setup a special URL that is unique per person and can be re-generated. Instead of the normal login page, you get this on-the-side page that is immune to account locks.

I'm sure there are lots of ideas, each with a trade off.

Re:Real lesson -- make guessing expensive!

[Gaygirlie]

Locking an account after 20 wrong guesses enables a simple denial-of-service attack by your enemies.

Adding an ever-increasing delay for the attacker's IP-address would more-or-less solve both issues.

Re:Real lesson -- make guessing expensive!

[TheRaven64]

That works fine, unless there is a botnet that is attacking you, with each bot trying 3 attempts on the same login. That's the attack pattern I see on SSH on my server...

Re:Real lesson -- make guessing expensive!

[rb12345]

The issue is that with unsalted hashes, you only need to use brute-force once to generate your rainbow table, at which point all the passwords are cracked simultaneously. (OK, in practice you would not wait for a full rainbow table to be produced; you'd download a list of pre-computed common passwords and start with those.) With salt and a strong password, you still have to do all of that brute-force work just to obtain a single password, even if you have several GPUs doing the calculations.

Re:Real lesson -- make guessing expensive!

[Algae_94]

You are correct that the fault of this is LinkedIn, however, blaming LinkedIn doesn't help anyone who's password was swiped.

The bottom line is trust no one. Assume that whatever site you are setting an account on will be compromised at one point and take steps to eliminate risk from that. Making a stronger password can help get your password into the 0.1% unknown when someone has cracked 99.9% of the dumped hashes. Not reusing passwords is even more important as it limits the spread of damage if the password does get cracked.

Perhaps an even better idea is to limit the number of accounts people make and have them really think twice about whether they need that account or not.

Re:Real lesson -- make guessing expensive!

[stretch0611]

Any secadmin/netadmin who has hashes available or allows unthrottled passwd guessing is INCOMPETANT. Staff are paid for professional-level knowledge so users do not need to be concerned.

Actually, in most applications you need to blame the developers. (Full disclosure I am a software developer) However, companies would prefer to pay crap wages to people who don't know what they are doing instead of paying people with experience and knowledge what they are worth.

In addition many companies do not want to pay to increase existing security as that money does not provide an immediate ROI. They want developers working on high visibility features so that they can charge customers to upgrade, A MBA does not see the value in security until after it gets breached.

Re:Real lesson -- make guessing expensive!

[F.Ultra]

You can't throttle offline cracking,

Actually you can sort of it you use any of the iterative hash models like bcrypt & co.

slashdot

[rapiddescent]

own up, who used the password slashdot - 0000003627a75d6c96a3d965247584a78779bc3d

Re:slashdot

[Anonymous Coward]

That was me.

Re:slashdot

[Anonymous Coward]

That was me.

That's your password you say?

HAHAHA DISREGARD THAT, I SUCK COCKS

Opportunity!

[Anonymous Coward]

Send me your password and I will verify that
-No one else is using it
-It is safe

BONUS: If you send me your credit card information I will tell if you if it's lucky!

THANKS,
"HAPPY DUDE"
742 EVERGREEN TERRACE

shared passwords

[DogDude]

Most people use the same password in multiple places. I'm guessing that 80% of those Linkedin email/password combinations will also get one into bank accounts, as well.

"Rules" ?

[Marc_Hawke]

Let me admit upfront, I've never explored the world of password cracking. However part of the article doesn't make sense to me. He mentions password based on rules. However he listed the rules and it seemed really strange.

pwdlink from pwlink with the rule "insert d in 3rd position"
pwd4link from pwdlink with the rule "insert 4 in 4th position"
pwd4linked from pwd4link with the rule "append ed"
pw4linked from pwd4linked with the rule "remove 3rd char"
pw4linkedin from pw4linked with the rule "append in"
mpw4linkedin from pw4linkedin with the rule "prepend m"
mw4linkedin from mpw4linkedin with the rule "remove second character"
smw4linkedin from mw4linkedin with the rule "prepend s"
sw4linkedin from smw4linkedin with the rule "remove second character"
lsw4linkedin from sw4linkedin with the rule "prepend l".

Does that mean he made a rule that added a 'd' to EVERY word in his dictionary to try that as a password? Or was his rule "any time you see a 'pw' it might stand for 'password' and therefore adding a 'd' makes sense."?

My point is, these 'rules' don't seem like generic rules at all, rather they sound like an 'after the fact' description of how to change 'pwlink' into 'lws4linkedin'.

Can anyone explain what I'm missing, or did he just add that for 'article filler?'

Re:"Rules" ?

[Anonymous Coward]

The guy who wrote the article is braindead, that's all

Clearly lsw4linkedin comes from pwd4linkedin (hint: look at your (QWERTY) keyboard). The author however made up some batshit crazy scheme to arrive at lsw4linkedin from pwlink. I guess I could make one to get there from "OMGpinkpony" as well

Re:"Rules" ?

[Rich0]

I'm not an expert, but basically you want to generate a large search dictionary. You start with a small one (like the english dictionary), and then apply rules to generate more words to search. The kinds of rules you listed are typical, and you start applying them individually, and in combination. So, if you have 1000 words, and 10 rules you apply individually, you end up with 10k words. If you allow permutations of 10 rules then you have 1k*10^10 or something like that (depending on the rules order may or may not be important).

Sure, that sounds like a lot of things to test, but compared to a full brute-force search it is still a greatly reduced space.

All of this comes down to diminishing returns. The only way to guarantee getting them all is a full brute-force. However, if you can get 900k with a single pass with common words and a simple set of rules in a few hours, that is probably good enough for most purposes. If all you need is one chances are you just need a dictionary.

Re:"Rules" ?

[Anonymous Coward]

There are a whole dictionary of rules, and they were all applied to the last "dicitonary" of found passowords. The size of the dictionary decreased on each iteration. the rules listed above are just a list of the rules that happened to be successful, and lead to the "deepest" found password of lsw4linkedin after 10 iterations of this process of applying a dictionary of rules to a dictionary of known used passwords. The rules above are the "lineage" that lead to that specific passoword.

Re:"Rules" ?

[SecurityTheatre]

If all you need is one chances are you just need the word "Password".

FTFY

Real lesson: some web devs should be out of a job

[zedrdave]

If so-called professional websites used proper hashing and salting, even password123 would be a halfway decent password.

Without offline cracking, password weaknesses aren't very exploitable (even the most inept server will shut you down after a couple hundred attempts at brute-forcing your way through an online login).

People like to harp on those "idiots" who pick weak passwords that can be cracked with a rainbow table, but unlike the moron web devs who still fail to salt their password DB in 2012, your grandma is not paid to have basic knowledge of computer security.

two factor authentication

[circletimessquare]

SMS to phone

coming to a computer near you, for everything

Re:two factor authentication

[Rob the Bold]

SMS to phone

coming to a computer near you, for everything

I have a wireless service that doesn't seem to work with anyone's SMS notification system, and I assume my provider's not the only one like this.

Re:two factor authentication

[Mashiki]

I strongly dislike SMS two factor, as smartphones are just as easy to get trojans/loggers on as PC's. Keyfobs work better, but then there's the possibility of the source+keystore being stolen. But at the end of the day both are more viable options than a simple password. Most people have cellphones, I don't but for anything important I already have a fob for it.

Re:two factor authentication

[complete loony]

No thank you. I don't have a phone contract, and I don't have any plans to get one.

Store a cookie of some kind on my PC if you want, and send me an email when I login from somewhere else before allowing access. But don't force me to sign up for a mobile phone plan.

Re:two factor authentication

[circletimessquare]

if something becomes the de facto standard, and it probably will since most everyone has a cell phone, then for cell phone averse people such as yourself they will probably send you a dedicated cheapo receive-only pager

Some more important questions

[arcctgx]

We all know that people tend to choose weak passwords, this is not really newsworthy. Ever since the database was leaked, many people, including professionals, have performed various analyses of cracked passwords. This is fine, but I think there are more important things we need to know right now:

1) When exactly was the database leaked? It seems that it's been floating around the internet for some time before it hit the news last week.
2) What the attack vector was?
3) What security measures have been taken by LinkedIn to ensure this will not happen again?

And perhaps one more: is there a relation between LinkedIn, eHarmony and last.fm database leaks? Did the same person/group do this?

Re:Some more important questions

[Anonymous Coward]

Those questions are the wrong and boring ones. Nobody gives a flying fuck about linkedin. The computer science bit is what's interesting in a case like this: How to make a good password? And then the psychology part: What kind of passwords do people use?

isolation 101

[epine]

This is a nice piece of work where he uses incremental modifications of existing password templates to show that password "seasoning" with a few stray twiddles such as s/o/0/ or s/$/! isn't worth much.

linkedin is the only social network I've signed up for, and I visit less than twice a year. Don't think I used a strong password, but I do know I used a password totally unrelated to any other password on any other active account.

Sure beats being the guy with the password lsw4facebook or lsw4citibank on sites that might be easy to guess.

Think of the poor crackers.

[MRe_nl]

"IfYouCanReadThisYou'reTooCloseToMyPrivats".

"PrivacyIsDeadDon'tYouAgree".

"YouWin,NowFckOff".

"BeingParanoidDoesn'tMeanNobodyIsReadingThis".

Re:Think of the poor crackers.

[jd]

Just remember, "Can'tinterruptwhileI'mtalkingOrthey'llconfiscateallyourguitarsAndcatch22saysifIsingthetruthTheywon'tmakemeanovernightstar" should always hash to the same value as "BernieRhodesknows,don'targue"

Hackers the movie

[bdrees]

Can they atleast confirm that the top five used password are still God, Love, Sex, etc etc, or what ever they were in that movie?

SMS to phone.

[zentigger]

I barely trust most web-service providers with an email address that can be closed/blocked/changed with little cost or effort. Satan will skate before I start giving out my mobile number!

Re:SMS to phone.

[circletimessquare]

then you aren't doing any banking or using Craigslist

I don't use facebook but I believe they are doing phone authentication now too.

It's coming for all sites, I'm sorry. It's good for security, I believe.

Re:SMS to phone.

[rwv]

Satan will skate before I start giving out my mobile number!

I do believe they have roller-derby in hell... so I guess zentigger will be sharing his or her mobile number soon!

On a serious note... I thought that was a clever euphemism for "when hell freezes over".

Re:SMS to phone.

[Anonymous Coward]

Meanwhile you can log into your cell provider using only UN/PW and change which phone is activated for a given line.

Re:SMS to phone.

[circletimessquare]

satan does skate:

http://en.wikipedia.org/wiki/Tonya_Harding

Re:SMS to phone.

[Cro Magnon]

Facebook might be doing phone authentication, but they're not forcing it (yet), and I sure wouldn't trust FB with my phone #.

Re:Real lesson: some web devs should be out of a j

[Anonymous Coward]

Why is it the devs who get the short end of the stick in most 'xyz should be fired!' comments in this topic?

I've worked at several places (in QA) where the devs were perfectly aware that there were security weaknesses (usually a result of some small system that organically grew into some big web service - but never was designed to be a big web service) - but until something is on fire (read: bad press), management tends to not prioritize highly needed refactoring (lets not argue over what to call it) over new shiny features.

Re:Check your password

[Jahava]

www.leakedin.org/

Nobody should use this site, period.

You seriously expect people to go to an arbitrary site and enter their password, knowing that the hashes have been leaked alongside account information?

In the kindest possible world this may be seen as a service, but the skeptic in everyone should hear very loud alarm bells. This site could easily log all of the passwords that are entered for "testing", use them to solve the harder-to-brute-force hashes, and deliver to the site operator the resulting account information and plaintext password!

Even if you had the best intentions posting that link, and even if the site actually is completely innocuous, one should never encourage any user to enter their password into a random third-party site. Please take it down immediately.

Easy access to corporate or government accounts?

[uslurper]

On linkedin you can see real people.. not just random net accounts. These people list their current job on Linkedin.
Someone could take their passwords, find out what company (or government agency) they work for, and download all their email.
Sell this information to hedge fund managers and investment corporations or tabloids whatever.
$$$ with no ???.

Re:Check your password

[glwtta]

In this case, you have all the tools to satisfy your inner skeptic: the source is right there, if you don't trust yourself to read it, it's trivial enough to examine all communication the page does.

As the site says, the passwords are hashed on the client, and nothing but the hash is ever sent to the server.

You make a fair point, but this is Slashdot, we're not supposed to be "users" here.

Must we use truly random passwords?

[Anonymous Coward]

So this was eye opening for me if nothing else. If you're not going to use something that generates and stores random passwords (say lastpass) - then you're forced to come up with something that you can remember. This means words, modified by "rules" - numbers and symbols attached to it. Basically this guy proved that strategy doesn't work.

So words and any rules applied to them are out. What next? Are we all forced to use truly random passwords for every single darn login we have (which in my case is literally hundreds). What about my current strategy of using obscure model numbers of things I like, and then modifying them? Is this safe or just as stupid as making a password "!pa$$w0rd"?

Couldn't locate the actual file...

[Anonymous Coward]

Has anyone located the correct zip or text file with the passwords in question? The hashes contained in the files circulating on the pirate bay have trailing zeros instead of their first characters.

Re:Check your password

[Jahava]

In this case, you have all the tools to satisfy your inner skeptic: the source is right there, if you don't trust yourself to read it, it's trivial enough to examine all communication the page does. As the site says, the passwords are hashed on the client, and nothing but the hash is ever sent to the server. You make a fair point, but this is Slashdot, we're not supposed to be "users" here.

You also make a fair point, and I'll admit I didn't catch that and replied hastily in light of that.

There are, however, a lot of known website tricks that can get around this (e.g., collaborating iframes, etc.) as well as server-side tricks (e.g., serve a malicious page every nth visitor). A full client-side audit will prove any given instance harmless, and I suspect the site likely will pass all such tests, but I still think the encouraged trust of a one-factor authentication credential to a third-party site is in bad security taste, especially as the link propagates outside of the "expert" community to relatives and friends who will likely not have the know-how to perform such auditing.

Thank you for pointing that out!

Upside to it

[Anonymous Coward]

Ironically this hack means that at least one person is actually accessing all these linkedin accounts.

Re:Check your password

[Talennor]

You realize that the concern many computer security people here have is that your password hash is available in the open. And you want to freely type it into another website? I don't care how much you trust this site. Don't do this.

This is the point

[Tim12s]

This is the point that you realise that the people with stronger passwords are the ones you want to throw more brute force processing into hacking their passwords because they have something valuable to hide.

Unfortunately, I know my password has been hacked which means that the entire segment of accounts with the same password are effectively compromised. Its not my linked.in account that is worth hacking as they attackers could be scraping information from other more valuable sites.

hash the usernames as well

[anonymous9991]

why not has the usernames as well? however even using salts is weak in this manner. You have to do more than just add salt and hash to have a decent measure of security. If you use only one algorithm you really do not care about security

Re:Check your password

[steelfood]

I've seen sites that just post the plaintext password. Maybe it's not the best thing to do, but at least you know what not to change your new password to.

irony

[Anonymous Coward]

...And you mispeled "incompetant".

so ?

[Anonymous Coward]

the file is password hashes alone , no username , so what ? they have the keys but n clue to what door they individually open , so lets say that a burglar has a copy of all the apartement in NYC but no clue to what key goes with what door , do you really think he'd try them all ? , not to mention that the news was widly spead and the time to live of those hashes got reduced to a couple days maybe ?

security is not limited to passwords

Sites that don't suck

[AdrianKemp]

There are only a handful of sites that I frequent that actually allow for useful passwords (ie. longer than 30 characters). Most are "between 4 and 12" or something idiotic.

As long as the people designing sites are inept and stupid, passwords will continue to be shit.

Re:Sites that don't suck

[jd]

Once upon a time, backspaces were legal password characters - if you knew how to add them. It was a method designed to get round early methods like watching people type or getting a screen capture - what you saw wasn't what the computer saw. That specific method wouldn't be useful in a world of keyloggers and packet intercepts, although it might still fool the hash table attacks (since the password that the hashing function hashes is NOT the password you type in).

Interesting to know what other techniques might exist.

no to fobs

[circletimessquare]

1. it's hassle for the company. you have to send to the customer, deal with customer service inquires for new ones/ lost ones, etc. it's now a logistics headache
2. it's a hassle for the customer. i have one for banking, and i'm always misplacing it, not having it when i need it, etc. just one more thing to keep track of in my life i don't want to. and a different fob for every important relationship? I have to carry around a jangle of fobs? Or leave them someplace and I can only do my banking there? No thanks.
3. everyone has a cellphone. everyone always has a cellphone easily available. they are going to replace your wallet anyways in the near future. so i wouldn't be surprised if cell phone companies, the government, and banks get together and decide to send you a receive text messages only widget, just for cellphone averse people such as yourself

Re:no to fobs

[Anonymous Coward]

...so i wouldn't be surprised if cell phone companies, the government, and banks get together and decide to send you a receive text messages only widget, just for cellphone averse people such as yourself

You mean a pager? :P

Re:no to fobs

[circletimessquare]

lol

What's a pager?

(i'm joking)

I heard he left her...

[publiclurker]

because she refused to properly secure her ports to outside access.

Re:I heard he left her...

[swarsron]

or vagina

Re:Check your password

[Anonymous Coward]

You realize you can also compute the SHA-1 of you own password with other means like BASH (and clear the history afterwards) and then enter the SHA-1?

As others said it also claims to hash the PW in JavaScript (so in your browser)?

Re:Check your password

[jekewa]

It may also be the case that the posted source has nothing to do with the actions of the site. I mean, maybe they're being really friendly and helpful, but maybe the evildoers are just smart enough to instill a false sense of security by giving you some otherwise valid source, that isn't doing what they're trying to accomplish at all.

The bit about watching what the site does with Firebug or other browser tools or network monitors, will really reveal their nefarious nature...

Re:Check your password

[ffflala]

That's a good point, and should be an obvious one. However it's easy enough to test without putting your current password at risk. Here's what I did:

1. Changed my LinkedIn password
2. Went to the site, entered a fake, almost certainly unique password. Result?

"Looks like your password was not leaked. Hooray!"

3. Entered my old password -- a password now not used on any account. Result?

Your password was leaked and cracked. Sorry, friend.

Re:Check your password

[clickclickdrone]

It's a fair point but I got the site details from Dave Windera, an award winning UK journalist who specialises in online security so I'd say it's pretty trustworthy. He knows his stuff, deeply. It's a pity it's now been modded down as it IS a useful resource. FWIW, it confirmed my password was in the wild. Bugger.

They'll never crack MY password!

[Anonymous Coward]

It's Jj2jt#5jgj*(892]60)81'>/sa SO THERE

aw crap

Re:Check your password

[glwtta]

It's not anything they posted separately, I just meant 'right click -> view source...'

I agree that not giving your passwords to such sites is a sound policy, but I also think it's good to actually check out if and how they could screw you, rather than just assume they can (by some dark magic).

Re:Check your password

[jekewa]

Heh...fair enough...I did, however, heed the "don't go there" warning. OK, in reality, I had no intention of going there; no interest, really. Just pointing out that provided source (and they're out there) doesn't always equal actual source).

PayPal + Fido (in Canada) don't mix.

[WoTG]

Yeah, you're not alone. I was happily using PayPal's 2 factor authentication that used SMS, and then it stopped working months ago. I haven't had a chance to figure out who to blame, Fido or PayPal. It's too bad, it was a good system, I wish my banks would do something similar.

No Lessons Learned From Cracking 2M LinkedIn Passw

[mug funky]

FTFY

Re:No Lessons Learned From Cracking 2M LinkedIn Pa

[jd]

Mistakes: See "Repeating Patterns"
Repeating Patterns: See "Mistakes"

Re:Real lesson: some web devs should be out of a j

[zedrdave]

Note that by the very generic "web dev", I meant merely the web dev team leader ultimately responsible for the decision to implement their login system that way and not to refactor it. Whoever was in charge of that part, regardless of management pressure, should have known better and clamour for a fix until they got one.
Even the most moronic upper exec will bow down to a strident warning that the user database might be vulnerable to "evil hackers" and consequences would be dire if things are left unfixed (you don't get to become upper exec without a modicum of ass-covering skills).

Also: refactoring a (decently designed) system to include salting is a relatively painless task. We aren't talking about a complete refactoring of the DB schema or whatnot.

Re:Check your password

[Anonymous Coward]

That was one of the funniest things about this whole story I can't believe that it returned "password hacked" to some of the stuff I entered i.e. assf**ker for instance. BTW that wasn't my real password LOLOL

heypete = a pussy (with NO BALLS)

[Anonymous Coward]

Running away from a challenge, little mere STUDENT boy? http://yro.slashdot.org/comments.pl?sid=2933305&cid=40421131

?

* Absolutely, and I take IMMENSE PLEASURE watching little wannabe computer guru NOOBS like yourself, a mere STUDENT, running away from a challenge that I put to you there in the link above, where I challenge you to disprove points of mine that show custom hosts files get end users of them the following items:

---

1.) Better "layered-security"/"defense-in-depth"
2.) Better online speed/bandwidth while websurfing
3.) Better "anonymity" to an extent vs. DNS request logs
4.) The ability to circumvent DNSBL's (DNS Block Lists) IF the user finds them inconvenient or unjust

---

(Now, I could care less for your pussy-like "std. evasion replies" here, but instead? Well - let's see you disprove my 21++ points in favor of custom hosts files in the link above, where you're running away like the scared little rabbitt NOOB you are!)

A few years ago, I "knocked-the-chocolate" out of a post doc student named StarKruzr (Jarrett DeAngelis) whom I also caught LYING as well, right here on these forums & also @ Windows IT Pro (where I also knocked the daylights out of Dr. Mark Russinovich of Microsoft as well on memory mgt. (MS too, I was correct that "dedicate all free memory to caches" would FAIL on Windows, because *NIX variants manage memory @ a GLOBAL LEVEL, rather than by process/atomic threads as well as showing his ideas incorrect by examples from MS themselves, then lastly correcting his work for "hardcoded" (blew me away a PhD would make errors like THAT) mistakes in pagedefrag.exe as well... which he ended up THANKING ME FOR no less in email also @ least!)).

I am going to laugh @ you since you have evaded a challenge put to you, and everyone else reading's seeing you do the same too... shame, shame, shame, lol!

You sure "talk big", but when the chips are put on the table in my challenge to you there in the link above? YOU RAN!

"Run, Forrest - RUN!"

(So much for student PUNKS like you, eh?)

APK

P.S.=> What's the matter pussy? Your grad school masters/doctoral training (good luck paying off your debts) not enough to face up to a challenge & face the music in the link above?? Obviously... you're WEAK, a punk, and you make me laugh! apk