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

Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords

ieeelog.com

Post reply on HN
Print view View original

61–70 of 138 posts

Re: Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords

#61

Post by Pyroshock »

ghshephard wrote: post #48
0003 wrote: post #43

Earlier quoted context omitted.

I am not too well-versed in this sphere, but I would also require salting passwords when hashing. It obviously won't help if your database is compromised, but will protect your users (and your database) against the effects of leaks such as these.

One of these days we will shut down the "Salting password hashes is a useful thing to do." meme from 1994. See: http://codahale.com/how-to-safely-store-a-password/ for details.

There's a reason key derivation functions like PBKDF2 and bcrypt still require a salt as an input.

Re: Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords

#62

Post by estel »

mercuryrising wrote: post #60
shanemhansen wrote: post #29

I understand that many organizations, even fairly large/respected organizations like the ieee work on a limited "IT" budget, but we've reached the point in our society where it's reasonable to expect these guys to do the bare minimum. Just like everyone working in a restaurant needs to know the basics of food handling in order to avoid getting people sick, everyone who's operating a website with logins has a responsi…

Can you send MD5 encrypted passwords over HTTP? Can you send passwords over websockets?

It's perfectly possible to use md5 to hash a password in Javascript before transmitting it by HTTP. There isn't a huge security benefit to doing so, however.

Re: Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords

#65

Post by vegardx »

trekkin wrote: post #64

Properly hashing/salting passwords on the client (in JavaScript) is more or less a must now. Client-side encryption is the next logical step. Although not perfect, it is better than storing plaintext data on the server.

It's a horrible solution. Just store them hashed on the server end, and make a secure connection. I would argue that more browsers support SSL than JavaScript...

Re: Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords

#66

Post by masklinn »

pbhjpbhj wrote: post #55
masklinn wrote: post #10

Earlier quoted context omitted.

> know how to md5 passwords MD5 is an utterly terrible password hash. It's just about as bad as plaintext. If you're hashing passwords with md5, please fix it and use one of scrypt, bcrypt or PBKDF2 (recommendations are generally in that order) with an acceptable load factor[0]. Go look up mozilla's coding security guide to know how to migrate from a terrible and insecure hash to a secure password hash. [0] the usual…

> It's just about as bad as plaintext. // Hyperbole is just about as bad as murder.

> Hyperbole is just about as bad as murder.

It's not hyperbole, a rainbow table will give you instant plaintext for 95% of your passwords. And even if you don't want to use one, an off-the-shelf high-end graphic card (~$500) can compute 10 billion md5 hashes per second, plug that in a not-completely-retarded brute-forcer (jack the ripper, oclhashcat) and you've got pretty much the whole database as plaintext in hours tops.

The only passwords you won't have plaintexted are those so complex you know the user doesn't reuse them anyway.

Re: Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords

#67

Post by masklinn »

larrys wrote: post #39
masklinn wrote: post #13

Earlier quoted context omitted.

> Because it's not that important. yes, it very much is. > In most cases what someone could do with my account is to view articles I have paid for That's not the problem with leaking plaintext accounts. If the user database is compromised, you can safely assume all of the site is and the site's data is leaked as well (or would be if anyone gave a fuck). The problem of cleatext (or easy to reverse) password databases…

"Most users reuse the same password again and again and again. Having their password leaked" Yes it is generally accepted that many users reuse the same password on different sites. But that is a separate issue and really has nothing to do with what has happened here or why proper security should obviously be followed. Not disagreeing with that. But I disagree with the fact that since the user does the wrong thing ma…

> Yes it is generally accepted that many users reuse the same password on different sites. But that is a separate issue

No. That's the one and whole reason why you're supposed to one-way encrypt passwords with a suitable hash: protecting the shared secret.

> But I disagree

So what?

> If it is, where are all the warnings on any site saying "make sure not to give us a password you use anywhere else". (I've rarely seen any warning like that, have you?)

Yes, I have. These warnings don't actually add to anything as they're not followed, and impossible to get followed without making the system so cumbersome it's unusable. Apart from using 2-factor auth. Which is an other "responsibility of the site operator" which I guess you wouldn't want foisted upon him as you seem to believe site operators are and should be irresponsible.

> one that informs people to make sure the password they use is unique to their site

A suggestion which will go instantly ignored by 99% of the users (on average, technical sites will probably be lower). The single % left already don't reuse passwords.

Re: Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords

#68

Post by masklinn »

ghshephard wrote: post #48
0003 wrote: post #43

Earlier quoted context omitted.

I am not too well-versed in this sphere, but I would also require salting passwords when hashing. It obviously won't help if your database is compromised, but will protect your users (and your database) against the effects of leaks such as these.

One of these days we will shut down the "Salting password hashes is a useful thing to do." meme from 1994. See: http://codahale.com/how-to-safely-store-a-password/ for details.

> One of these days we will shut down the "Salting password hashes is a useful thing to do."

Uh? Why? It is a useful thing to do. More than that, it is necessary (but not sufficient). There's a reason why all of pbkdf2, bcrypt and scrypt generate salts if you leave them to their own devices.

> See: http://codahale.com/how-to-safely-store-a-password/ for details.

You completely misunderstand the article.

Re: Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords

#69

Post by andreasvc »

hnriot wrote: post #41
ithcy2 wrote: post #32

Earlier quoted context omitted.

You'd better be prepared to fire half the corporate world. And then do it again the next month. Because people will never stop doing this.

any decent corporate IT dept make sure you don't by forcing often password changes and having quite secure rules for length and charactes in a password. My corporate IT force quarterly password changes for VPN, NIS and SSO, which all must be different, all must be 8+ characters, all must have mix of upper and lower and numerics. They also store the hash of all previous passwords to prevent users from recycling. So I…

Forcing people to change their password is one of the most annoying and ineffectual things you can do. It is completely useless to change a perfectly good password when it has not been comprised. And since most humans have trouble memorizing complicated passwords, the net result will be much simpler passwords, or ones that get written down.

There's no technical solution to this problem. In the end it comes down to making people actually memorize pseudorandom passwords. As long as there's no shoulder surfing or keyloggers, you can keep such a password for years.

Re: Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords

#70

Post by omra »

estel wrote: post #62
mercuryrising wrote: post #60

Earlier quoted context omitted.

Can you send MD5 encrypted passwords over HTTP? Can you send passwords over websockets?

It's perfectly possible to use md5 to hash a password in Javascript before transmitting it by HTTP. There isn't a huge security benefit to doing so, however.

Only doing that won't help. You might as well be transmitting the password, since someone can just copy the hash and then it would be equivalent to having the password. (Also known as a Pass the Hash attack, http://en.wikipedia.org/wiki/Pass_the_hash).
Post reply on HN