Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Change your Last.fm password

thenextweb.com

Post reply on HN
Print view View original

91–100 of 152 posts

Re: Change your Last.fm password

#91

Post by darklajid »

kalininalex wrote: post #79
jameswyse wrote: post #60

@CrackMeIfYouCan posted this on twitter: A bit of stats on last.fm leak: 1) It happened a WHILE ago. 2010/2011 2) 17.3 million raw-md5 3) 16.4 million cracked. 95% cracked.

Any info on how and why so many were cracked? Passwords too simple?

MD5, unsalted. On commodity hardware you can compute those blazingly fast. A brute force attack, ignoring word lists, is totally possible.

That's ignoring all the resources that offer access to precomputed hashes (I don't want to call a list of MD5 hashes a rainbow table).

Easy or not, passwords saved with this scheme are unprotected.

Re: Change your Last.fm password

#92

Post by phase_9 »

kalininalex wrote: post #79
jameswyse wrote: post #60

@CrackMeIfYouCan posted this on twitter: A bit of stats on last.fm leak: 1) It happened a WHILE ago. 2010/2011 2) 17.3 million raw-md5 3) 16.4 million cracked. 95% cracked.

Any info on how and why so many were cracked? Passwords too simple?

Unsalted MD5s. http://www.codinghorror.com/blog/2012/04/speed-hashing.html

Re: Change your Last.fm password

#93

Post by cf0ed2aa-bdf5 »

obituary_latte wrote: post #53
anigbrowl wrote: post #47

Jeepers, I just changed my linked in password. I had the source for PGP back in 1993, I don't recycle passwords for anything remotely important, I use gnarly long passphrases, two factor authentication and what-all else, and I AM SICK OF IT. I'm beginning to think that IBM had the right idea witht he thumbprint scanners in the laptops. I'm tired of the maintenance security imposes on me, the lack of a meaningful indu…

Funnily enough I opened a new bank account the other day (Chase) and to my surprise they don't allow special characters to be used in the passwords. It indeed appears that the entire system is broken beyond repair. It seems like it is becoming the norm to expect to be exploited at some point so the de-facto preemption is to have someone to blame. As the manager of a datacenter we recently moved into said "we're here…

My (German) bank only allows passwords up to 5 characters.

When I ranted about it on twitter some IT guy from a local branch commented about that is totally enough since they do an hour lockout after 3 wrong tries.

I'm thinking about switching banks now...

Re: Change your Last.fm password

#94

Post by SourPatch »

raverbashing wrote: post #19
tptacek wrote: post #2

17.3 MILLION MD5 hashes (unsalted, not that it matters), of which over 16 million have already been cracked.

What?! This means next leak will be one million CRC32 password hashes? Or maybe LM hashes. Or crypt on old /etc/password files

Don't forget last year around this time when Sony's PSN was cracked into and it turned out they were storing the cleartext passwords.

Re: Change your Last.fm password

#95

Post by powersurge360 »

raverbashing wrote: post #49
cschmidt wrote: post #44

Earlier quoted context omitted.

Yes, that's exactly what you do. In Django 1.4 (the latest), they store passwords using PDKDF2 or bcrypt. The nice thing is that it automatically upgrades the hash function if it used to be something else: _______ Password upgrading When users log in, if their passwords are stored with anything other than the preferred algorithm, Django will automatically upgrade the algorithm to the preferred one. This means that ol…

Kudos to Django because this is very important Like in bcrypt discussion saying you can tune the amount of work. Sure, but what to do with the existing hashes! Of course, the user needs to retype their keys, but it's better than keeping old credentials. (or maybe you save the original credentials with strong PK crypto, together with the hash, then periodically decrypt offline and rehash)

In regards to "what to do with the existing hashes" bcrypt can detect the original work factor and hash to that. Not sure how you would upgrade that for users, however.

Re: Change your Last.fm password

#96

Post by powersurge360 »

raverbashing wrote: post #49
cschmidt wrote: post #44

Earlier quoted context omitted.

Yes, that's exactly what you do. In Django 1.4 (the latest), they store passwords using PDKDF2 or bcrypt. The nice thing is that it automatically upgrades the hash function if it used to be something else: _______ Password upgrading When users log in, if their passwords are stored with anything other than the preferred algorithm, Django will automatically upgrade the algorithm to the preferred one. This means that ol…

Kudos to Django because this is very important Like in bcrypt discussion saying you can tune the amount of work. Sure, but what to do with the existing hashes! Of course, the user needs to retype their keys, but it's better than keeping old credentials. (or maybe you save the original credentials with strong PK crypto, together with the hash, then periodically decrypt offline and rehash)

In regards to "what to do with the existing hashes" bcrypt can detect the original work factor and hash to that. Not sure how you would upgrade that for users, however.

Re: Change your Last.fm password

#97

Post by pnathan »

7952 wrote: post #58
pavel_lishin wrote: post #16

Earlier quoted context omitted.

I find it so odd that this functionality wasn't baked into web browsers from the beginning.

TLS does allow client authentication using keys. It is a flawed solution as it puts too much importance in protecting the key. What happens when you need to login from an internet cafe? How do you securely move keys between devices? What happens when the machine has malware that steal the keys? Good security assumes that everything can and will be compromised and provides defence in depth. Client certs do little to h…

That problem is pervasive with any sort of private key system, as well as the password databases becoming popular.

Private key files pose a challenge, absolutely. But is it so much worse than having every company Jack store passwords in $non_crypto_hash_system?

(begin-rumination....

Right now, compromise risk for credentials typically lies on the companies. They frequently fail in protecting these credentials. However, your credentials are - inadvertently - distributed out between multiple companies. When one goes down, the other credentials are considerably less affected.

(More so if you've been bad and used the same password everywhere).

Examining a local store, we centralize risk onto the local desktop. Suppose that in order to log into the user's central system, the user had to provide a password. (Example: gpg-agent). Then, to log into a remote system (web, ssh, etc), the user's credentials get passed into the remote system via some well-known private/public authentication scheme.

Points of failure here:

- user forgets own password. All credentials are lost until they manage to get reauthenticated into the system.

- Malware hacks the user's keystore and uploads private keys to $malware_database. Case 1: in-memory hack. Case 2: hacks system database.

- Case 3-ish. Malware injects dialog requesting system password and gullible user enters it. Upload commences...

I am sure other scenarios can be imagined. In these scenarios, the risk is shifted from the company onto the user (and the key storage engineers).

I can imagine that password forgetting would be heniously problematic and cause PR disasters: many people don't like to take responsibility)

Re: Change your Last.fm password

#98

Post by pek »

EvilTerran wrote: post #69
pek wrote: post #50

Earlier quoted context omitted.

Couldn't you just move from, say, using MD5(password) to bcrypt(MD5(password))? So when it becomes apparent that the old hash is no more secure, start using the combination of the old bad hash (MD5) and the new good hash (bcrypt). This way you can simply run once through the password database, hash each password hash there with the new better hash, and throw away the old hashes. No need to prolong the process until t…

As hashing functions aren't injective, composing them leads to a reduction of range (ie, a smaller set of possible output values). As such, (bcrypt . MD5) would almost certainly be a weaker hash than bcrypt alone. Might not be enough to make a difference, but I'd consult a cryptologist before betting on that.

Yeah, it would be weaker against a collision attack. But that shouldn't be a concern as the purpose of the password hashing function is to protect against a preimage attack: finding the password given its hash. I can't see how the composition could be more vulnerable to a preimage attack than its parts. (Provided that the inner function's output is evenly distributed.)

Re: Change your Last.fm password

#99

Post by anigbrowl »

zerostar07 wrote: post #80
anigbrowl wrote: post #47

Jeepers, I just changed my linked in password. I had the source for PGP back in 1993, I don't recycle passwords for anything remotely important, I use gnarly long passphrases, two factor authentication and what-all else, and I AM SICK OF IT. I'm beginning to think that IBM had the right idea witht he thumbprint scanners in the laptops. I'm tired of the maintenance security imposes on me, the lack of a meaningful indu…

What about browserid, openid etc

I'm not really knowledgeable enough to rate different solutions, which is why I resorted to ranting rather than articulating a good alternative or working on one myself. Security is something that I have to do rather than something I am personally excited by, and I don't actually want to be encrypting everything for the same reason that I don't want to live in a bank vault or build a ten foot wall around my property.

I guess what I'm saying is that I will pay for a frictionless system whose operator is prepared to place a cost on failure, same way that I am willing to pay for a decent padlock or mortise lock for my physical property. It doesn't have to utterly impenetrable, but I would like the security provider to have skin in the game.

I thought openID was an excellent idea; I'm not sure why it didn't take off, maybe Google took too much of a monopolistic approach or something.

Post reply on HN