Hacker News Reader

Comment by capnrefsmmat | Hacker News Reader

I use a much simpler version of the idea in the form of PwdHash: https://www.pwdhash.com/

Before submitting passwords to a website, they're replaced with a hashed version which incorporates the domain, so passwords are unique to each domain. (The hash isn't anything fancy, so it could definitely be modernized with scrypt or bcrypt or whatever is fashionable.)

I've used it for years and it always works well, apart from the sites that claim my password is too long. It requires no support from the website, just a simple browser extension.

View on HN

What happens if your password is leaked? It seems to generate the same hash every time, so you would have to change the site password. And if you have to start remembering "Well my password for every site is 'pumpkin' EXCEPT for Wordpress, where my site password is 'bagel'," that list is only going to grow with time as websites inevitably get hacked. So once you've got five or so site-specific passwords, how is it any better than the password memory problem this was originally trying to solve?

I thought about using pwgen locally with a combination of domain, username and password as a hashed seed. But like you mentioned, trying to remember how often i had to change the password (or had restrictions applied only at a particular site, which are pretty ridicules sometimes) makes this not really a worthwhile solution. Albeit this, its not completely useless. If you have specific rules how to create new passwords (a counter for example) and to circumvent specific restrictions, one could iterate through the possibilities rather quickly. One thing that's unbeatable about this solution is that no password store is needed and so none could be lost, which drove my initial thought to this.

I don't hate the idea, but I could never use this while so many sites still have dumb validation rules. It would drive me crazy if I had to remember what sites this didn't work with.

Their generation isn't great. They should tweak the resulting password to ensure that it passes most common tests. I think I would enforce

   - 10 characters
   - at least one punctuation
   - at least one digit
   - at least one upper case
   - at least one lower case

By coercing the password to have this form you're losing a trivial amount of entropy, but you'll pass the vast majority of password policies.

Also add a nonce to the password generation (1, 2, 3, 4) so that you can change it if needed or required. No need to remember the nonce, just try a few until you can login.

I don't remember where off the top of my head, but I'm pretty sure I've seen sites that had a "no punctuation in passwords" rule. I think at least one of them was a bank.

Makes sense, it's so their IT department can read it to you more easily over the phone.

Nespresso is one that immediately comes to mind as it's the most recent I've encountered besides my bank. I went to order some pods for my mum as a gift only to discover that their password restrictions were not only draconian but stupid. The moment a site prohibits punctuation (especially single quotes as they did) is the moment I suspect they're storing passwords in plain text.

It's not directly related, but I'm reminded of this Hall of Shame I stumbled upon from some HN comment a few weeks ago: http://plaintextoffenders.com/

PwdHash only puts punctuation in generated passwords if the password you provide has it, so it tries to be smart.

Also, some sites have things like capital letter cannot be the first character. Punctuation can't follow a digit. At most 8 characters... The list goes on.

See my other comment in this subthread about my own version of the deterministic password generator concept. It allows passwords to have site-specific rules for how they're generated and also allows rotating individual site passwords.

PwdHash has serious usability issues: http://people.scs.carleton.ca/~paulv/papers/usenix06.pdf

In particular, the fact that you type your password into the password field means that failing to invoke PwdHash means you either register with your raw password (making it worse than useless) or just leak your raw password with failed login attempts.

The password manager model (e.g. LastPass) is clearly superior in my opinion because the user doesn't know their passwords. Largely the only way to input your password is the correct way. Also determining the password for one site provides no information for others (assuming you're random generating the passwords). For PwdHash, if you crack the password you have a lot of information for breaking all the user's other accounts (because presumably they're reusing the same base password).

I used to use that too before I adopted a password manager.

Pwdhash uses md5, which is relatively fast. According to the below, even a strong master password could be derived in less than about 30 days.

https://security.stackexchange.com/questions/52355/how-secur...

On the other hand, the odds you'll be the victim of such a targeted attack are presumably pretty low. This at least gets you out of the category of "low-hanging fruit" for an attacker.

Why not just use a password manager?

Reply on news.ycombinator.com