Hacker News Reader

Comment by danielweber | Hacker News Reader

Because it's not that important. In most cases what someone could do with my account is to view articles I have paid for, either piecemeal or as a subscription. It's much more in their interest than my interest to keep that private.

They've sent me my cleartext password several times before I finally wrote it down in a place I could keep it safe, and I was always thankful.

Also, the default password is something very simple per account. I don't want to go into any more detail on that.

View on HN

> 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 is twofold:

1. Most users reuse the same password again and again and again. Having their password leaked on site 1 means all of their accounts are now wide open to whoever got the passwords.

2. Even if only the passwords themselves are leaked, this provides a huge dataset of effective, real-world password. This is a treasure trove of human behaviors and enables the improvement of brute-forcing mutators. In fact, one of the most substantial and important events in modern hacking history was the RockYou password leak.

You seem unfamiliar with the specific case. It wasn't the user database that was compromised.

It was plainly obvious to any user of IEEE that they were storing your password in clear text. Because they would, y'know, mail it to you. And the mail would have live hyperlinks to access your account, which generally means GET requests.

> You seem unfamiliar with the specific case. It wasn't the user database that was compromised.

Which isn't really relevant. A password leak is a password leak, whatever its source is.

> It was plainly obvious to any user of IEEE that they were storing your password in clear text

And nobody every took issue with that?

> And the mail would have live hyperlinks to access your account, which generally means GET requests.

That doesn't mean anything, the hyperlink could have contained a nonce allowing log-in.

Which isn't really relevant.

Then please don't bring it up, i.e., say things like "if the user database is compromised, you can safely assume all of the site is".

And nobody every took issue with that?

Maybe they did, maybe they didn't. IEEE members are probably slightly more informed than your random AOL user. There are plenty of mail managers out there that mail you your password automatically every month.

A password leak is one of several ways in which a user database can be considered compromised. Beside the fact that every leaked user had access to every other leaked user's database record, which is a huge breach in itself, how do you know that no administrative credentials were leaked?

The user database was compromised in a major way, even if nobody got root.

"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 many times, it is the responsibility of the site operator to assume that in the building of their product (in the way this issue is being discussed). 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?)

Of course this is all a matter of degree. There are many cases where you have to prevent users from their folly. True. My question is simply while there are many ways that sites try to enforce correct password behavior, I've yet to see (meaning if it exists I haven't really noticed it whereas I've notice other password thoughts) one that informs people to make sure the password they use is unique to their site AND the other typical restrictions (length, mixed case etc.)

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

Sure, you can do all of these things, and being able to view IEEE papers is not exactly the worst of problems. Now please let me know if I'm incorrect (and I hope I am), but it appears that in addition to viewing research papers your IEEE Web Account also lets you modify your @ieee.org e-mail alias account (if they have set one up; if not, they can create one) [1].

If so, it should be quite interesting if someone uses the IEEE Web Account username/password to re-forward your @ieee.org e-mail somewhere else. I can see all sorts of nefarious activities that can result from this, such as clicking on various "I forgot my password" links that also use your @ieee account in order to get access to other, perhaps more important resources.

[1] http://eleccomm.ieee.org/

You realize that people use the same password on multiple sites?

given that people signed up using corporate email addresses, this could be used to hack internal networks of companies.

Using a corporate password for any other site is a firable misconduct.

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 think the onus of responsibility lies with corp IT and not HR.

You know how people that work at your company remember their passwords after having to change them so often and comply with so many rules? They write them down on post it notes that they leave at their desks.

Nice work!

These are all general password policy "best practices", and typically result in users using something along the lines of

FuC|Kj0017GUy-1 FuC|Kj0017GUy-2 FuC|Kj0017GUy-3

Or, for users who are lazier (read: most of them), you get:

S3P-2k12 0c7-2k12 n0V-2k12

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.

Reply on news.ycombinator.com