Hacker News new | past | comments | ask | show | jobs | submit login

"The answer" doesn't exist and it never will. Everyone has to do their part. Services that store passwords in plaintext should definitely be publicly shamed, every single time.



The problem is that "publicly shamed" means "shamed amongst security geeks". Most websites main demographic is not security geeks.


I dunno, things like this make their way to more mainstream media too, making "the general public" more conscious of security, and making them wonder whether their passwords will be secure at parties they leave them at.


The spin in mainstream media always puts the blame squarely on the hackers, and in my anecdotal experience typical users have no interest in the argument that the companies that were hacked are to blame.


Because most people have not even thought of the possibility that password can be stored in anything but plaintext, and take it as granted that all websites do. Thus the websites can't possibly be blamed, and the hackers must be the bad guys.


Not necessarily. If a relatively mainstream news site reported the event and quoted a security professional saying: "Website X didn't even try to keep your love life and dating profile a secret. Every single user's password is now publicly available. If you use the same password on multiple sites, be sure to change it quickly!"

I think even the most non-tech people would react to such a news story.


The adobe breach was fairly widely reported, but how many designers have sworn off adobe products? The same thing could be said about Linkedin or Microsoft products in the 90s.


It means being shamed among tech professionals and that's exactly the community in which those responsible for the disaster have to spend the rest of their professional lives. Peer pressure is very effective.


We don't even know specifically who is responsible for this particular thing, as I've mentioned in other comments it's likely this came from some non tech person anyway.


True, but I think this is one of those instances where you kind of have to take what you can get in terms of negative PR for Cupid Media and other companies that store passwords stupidly.


A browser plugin that pre-hashes anything in a hidden text field (with a user secret key and the password origination domain) could mimic this as a layer on top of existing technology.

It would have the obvious portability issues, and I'm sure other implementation issues.


Your idea sounds like an automatic version of SuperGenPass: http://supergenpass.com

I've been running it for years, which feels quite nice when sites start leaking passwords left and right.


How have I functioned as an adult for so long without knowing that this plugin exists?

Thank you for sharing, I am going to download this immediately. My current algorithm for passwords is human based so it is an unfortunately simple algo. It provides some additional security over raw reuse but not enough for me to be comfortable.


This is (hopefully) a problem that platform owners can solve for us, and if they do I'll love them for it, but they very likely won't take it on.

Apple/Google/Microsoft can bake in cross-device syncing into the browser/OS and apply this sort of thing on form auto-fill.

It'll break down when:

a) Hashes don't meet site-specific password requirements (too long, missing special characters, etc.)

b) Sites store passwords in plaintext and you forgot your password and ask for them to email it to you (user: What the hell is this garbage of text, I didn't type this in!)

Unfortunately the above problems usually occur on sites where you need this most, and are very hard to solve, and so this problem is therefore unlikely to be solved "neatly" by anybody big.


If I understand you correctly, that exists already and is called pwdhash: https://www.pwdhash.com/.

Available online and as browser plugin for the major browsers.

The already mentioned supergenpass seems nice as well.


well, you could even do it manually

echo 'this is my pass' | shasum 3b0c5dc943cd30dcd2ca1ff760145f219d3ba3f3

And use that as the password. Of course, this is a very basic example, you should make it more safer by adding a salt and running more iterations.

May be easier (and safer) than installing "One password" kind of software.


That doesn't quite work in the unfortunately common case of user password re-use. If your hash is constant and stored in plain text somewhere and that place gets hacked -- then your password at every site is compromised.


If you use an actual bash script instead of a one-liner, and you can do things like 'silently' read in the password with `read -s` in the standard *nix convention, even read it twice to avoid mistyping your master key and temporarily locking yourself out of an account you just created.


Here's a tentative crude solution

http://pastebin.com/MuV8vtcR

you can pass a "salt" as the first argument as well (it will merely be concatenated with the password)


You should quote your vars in the if check, otherwise it doesn't handle spaces very well. (And really the master key should be a master passphrase.)

A few years ago I whipped this up: http://www.thejach.com/public/pw2 (I don't recommend other people use it but it works for me.) I type in something along the lines of "my secret passphrase ycombinator.com". It doesn't do hash iteration and uses the hash as a seed to Python's RNG which I use to get random bytes and then have a password character-space of any printable character -- it also outputs an alpha-numeric version along with different string sizes to handle those dumb sites that put restrictions on your password.


Yes, you need to add a salt, it can be the URL (and something else added)


echo "this is my pass for $URL" | shasum


Awesome idea, should randomly salt them for users who insist on using the same password for different sites.


"i created my account on machine x, now i can't log in from machine y".


Might be an extreme comparison (beg your pardon if I'm being naive), but it's a similar hinderance to using SSH keys. Carry it around on a USB key, or deal with the security outweighing convenience.


I like that. Could even be coupled with a portable browser.


What about determining the salt from the domain for the given login? (perhaps slightly more refined than that to mitigate cases like *.google.com)


I think that's right. It would also need some ability to add mappings like "when I log in from gmail.com, hash like it is google.com"


That being the obvious portability issue.


I propose a scarlet letter "P" (for plaintext).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: