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

111–120 of 138 posts

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

#111

Post by jlgreco »

EvanAnderson wrote: post #88
runn1ng wrote: post #85

Earlier quoted context omitted.

If you want to have a shared folder that you share between people you trust, it's still the simplest solution. It's very low-level, but it works. Yes, you can buy a cloud offering, but physical disk is still way cheaper than "cloud disk". You don't have all the cloud features, but on the other hand, the data are 100% yours, on a server that you control.

I don't buy that it's "the simplest". Just about every major Linux distro ships w/ SFTP enabled out-of-the-box. How is installing an FTP server easier than just using the built-in SFTP server? I've been trying to actively discourage the use of FTP for the last 10+ years. It's not an option because it passes passwords in-the-clear. Protocols that pass cleartext authentication should just be off the table today.

I find that positive attitudes towards FTP often seem to correlate with positive feelings towards Telnet, and both seem to correlate with "Not really that comfortable with Nix"*.

The number of times I have had to correct tech-ish friends when they talk about "telnet-ing" into servers is frightening. All of them were relatively technology literate but either didn't do it for a living or got into doing it for a living "by accident". Think your physics major buddy who has only ever used windows on any computer that he owns.

You put people like that in the position to make a call, and I assure you you'll have an FTP server running somewhere in 5 minutes flat.

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

#112

Post by geofft »

bigiain wrote: post #108
runn1ng wrote: post #86

Earlier quoted context omitted.

OK, please educate me. (Take me as a model web developer.) I occasionally quickly hack some stuff together in php/javascript/html. I never figured out what should I do exactly to actually set up Apache to work with https, without needing to pay some money to some authorities. I just have a simple LAMP server and I don't really understand Apache. How do I make it "https"?

OK, please educate me. (Take me as a model restauranteur.) I occasionally quickly cook meals in my kitchen. I never figured out what I should do exactly to set up the dishwasher with detergent, without needing to pay for the detergent. I just have a simple kitchen and I don't really understand dishwashing. How should I make it "hygienic"? (That guy would get shut down by the health authorities as soon as he started s…

Because most people grow up knowing how to use dishwashers, but not knowing how to use SSL. Until we get to that point, we should focus on educating and informing people instead of snarking at them and hoping they get shut down.

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

#113

Post by geofft »

nostromo wrote: post #102
runn1ng wrote: post #86

Earlier quoted context omitted.

OK, please educate me. (Take me as a model web developer.) I occasionally quickly hack some stuff together in php/javascript/html. I never figured out what should I do exactly to actually set up Apache to work with https, without needing to pay some money to some authorities. I just have a simple LAMP server and I don't really understand Apache. How do I make it "https"?

A simple way to side-step the issue entirely is to use an OAuth provider you trust. If you'll allow me to shamelessly self-promote. We make it really easy to do this correctly using an email and password at my startup: https://www.dailycred.com/

That can't possibly work, right? If a user accesses my website over unsecured HTTP, gets sent to an HTTPS DailyCred (or other OAuth provider) site to log in, and back to my unsecured HTTP site, they're still as vulnerable to man-in-the-middle attacks as if the OAuth provider didn't use HTTPS.

In particular, a man-in-the-middle can capture the redirect to DailyCred and instead send the user to some trojaned site to capture their username and password (and then forward it on to you to get a legitimate token, but the password's been leaked in the process).

I don't think it's helpful to say "we do HTTPS so you don't have to". Your users still need to be using HTTPS and preferably HSTS, unless I'm misunderstanding the intended use case. (I'm very happy to see that you guys do HSTS, though!)

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

#114

Post by geofft »

EvanAnderson wrote: post #88
runn1ng wrote: post #85

Earlier quoted context omitted.

If you want to have a shared folder that you share between people you trust, it's still the simplest solution. It's very low-level, but it works. Yes, you can buy a cloud offering, but physical disk is still way cheaper than "cloud disk". You don't have all the cloud features, but on the other hand, the data are 100% yours, on a server that you control.

I don't buy that it's "the simplest". Just about every major Linux distro ships w/ SFTP enabled out-of-the-box. How is installing an FTP server easier than just using the built-in SFTP server? I've been trying to actively discourage the use of FTP for the last 10+ years. It's not an option because it passes passwords in-the-clear. Protocols that pass cleartext authentication should just be off the table today.

I believe that random Windows authoring software is vaguely more likely to have FTP built in than SFTP. (But finding good SFTP software for Windows, e.g. WinSCP, is not hard, so this is not much of an argument.)

It's also the case that SFTP requires giving someone an actual user account on your UNIX box, and preferably knowing enough about how to set SSH up to restrict them to SFTP access only. If your server is much more valuable than the data and you don't trust yourself not to get SSH configuration subtly wrong, it's not terribly unreasonable to prefer installing an FTP server to adding a local user and giving someone else a password to it.

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

#115

Post by geofft »

astrodust wrote: post #56
jimhefferon wrote: post #53

Earlier quoted context omitted.

How do you dir on http?

If this is your problem, FTP is not your answer.

Which makes me wonder why approximately everyone has a parser for the common FTP directory listing formats, but I'm not sure I've seen any HTTP client that parses Apache mod_autoindex output or the other big servers' equivalents.

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

#116

Post by geofft »

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?

The right way to do that is Digest authentication, which is a challenge-response mechanism (so you never actually send a password or something equivalently stealable). I call it the right way mostly because it's built in to just about all servers and clients; doing it over HTTP is still not a terribly good idea.

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

#117

Post by nostromo »

geofft wrote: post #113
nostromo wrote: post #102

Earlier quoted context omitted.

A simple way to side-step the issue entirely is to use an OAuth provider you trust. If you'll allow me to shamelessly self-promote. We make it really easy to do this correctly using an email and password at my startup: https://www.dailycred.com/

That can't possibly work, right? If a user accesses my website over unsecured HTTP, gets sent to an HTTPS DailyCred (or other OAuth provider) site to log in, and back to my unsecured HTTP site, they're still as vulnerable to man-in-the-middle attacks as if the OAuth provider didn't use HTTPS. In particular, a man-in-the-middle can capture the redirect to DailyCred and instead send the user to some trojaned site to ca…

All of our inbound links and API calls from our clients are https from the get go. However, you are correct that a man-in-the-middle could rewrite the http website of someone using us to change the links to http from https and then perform a man-in-the-middle attack on that request.

Because of this narrow risk, we encourage our clients to still get ssl certs as they grow. However, when they are small MVPish non-sensitive apps with 50 users, the risk of this kind of attack is very small. (For example, Facebook Connect, which has the same vulnerability I described, would be a much more obvious target with a very high payload.)

The way we see it is getting people who are about to either store plaintext passwords or not salt their hashes correctly or pass them over non-https (like HN by default, boo!) or mess up a dozen other things, we're much more secure.

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

#118

Post by masklinn »

pbhjpbhj wrote: post #74
masklinn wrote: post #66

Earlier quoted context omitted.

> 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…

Really? 155a7a01308fa0807f722c5984bd91fb --- I find "high-end graphic card (~$500) can compute 10 billion md5 hashes per second" a bit unbelievable [but that's progress for ya]. So that's roughly all possible alphanum characters of stringlen 6, each second. So if my calculation is correct (assuming 60 alphanum chars randomly chosen) that's only 7000 years to calculate all 12 char strings? Yes I realise that md5'ed pa…

> 155a7a01308fa0807f722c5984bd91fb

You may want to read the last phrase of my comment.

> I find "high-end graphic card (~$500) can compute 10 billion md5 hashes per second" a bit unbelievable

And yet those are the numbers oclhashcat lite publishes for 0.10 on a stock Radeon HD6990 (10886.3M c/s): http://hashcat.net/oclhashcat-lite/

> Yes I realise that md5'ed password strings aren't random

Which is the whole point, and the knowledge the tools I mentioned use: https://community.qualys.com/blogs/securitylabs/2012/06/08/l... (note: the article is about sha1 hashes — which are about 3 times as expensive to compute as md5 — and is done on an older CPU, not GPU-assisted hashing)

> Just saying.

Just saying absolutely nothing?

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

#119

Post by ZoFreX »

ghshephard wrote: post #71
masklinn wrote: post #68

Earlier quoted context omitted.

> 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.

It's implicitly understood by everyone who cares about this topic that salting is intrinsic to KDFs. I.E. by the time you've read through, and understood http://codahale.com/how-to-safely-store-a-password/ , you understand why "salting" your password gains you nothing, because rainbow tables are no longer particularly relevant to cracking passwords. And yes, while there is salting inherent to KDFs, that's not the maj…

> rainbow tables are no longer particularly relevant to cracking passwords

If you use a common hash with no salt you can bet your britches the attacker will use rainbow tables!

It's also worth pointing out that rainbow tables aren't the only attack you are exposed to if you don't salt your passwords - it also prevents finding collisions, and massively slows down forward hashing attacks.

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

#120

Post by ZoFreX »

batista wrote: post #77
ZoFreX wrote: post #46

Earlier quoted context omitted.

> It obviously won't help if your database is compromised Good news, everyone: it will!

No, it won't. They can just write a new password + salt in the db and get in as that user.

Well, we need to define the attack if we're going to talk about what will and won't help. Generally when we talk password security, we assume the attack is to discover a large number of users' passwords, not to spoof as one. Additionally, it's more common to get read-only access to the data than it is to be able to execute arbitrary queries against the DB.
Post reply on HN