Hacker News Reader

Hacker News

Comment by momania | Hacker News Reader

Full thread

momania

- A decent minimum password length, without any funky requirements, just the minimal length.

- Being able to prosecute any company that stores passwords in plain text

View on HN

- no max length on password at all, or allow a 3 digit number of chars. Never silently truncate passwords either.

- never disable paste on a password field.

You'll have half your users with passwords like '123'. You could say it's the user's fault and their account is compromised, but when it's half the users on your site, really your site is compromised.

Better to have a minimum password entropy.

I understood the parent comment as the password length should be 3 digits long (hundreds of chars) rather than password itself.

Correct, though I would phrase it as "the password can be 100s of chars long, if the user so chooses"

i.e. No noticeable maximum length for people using password managers and generating 30, 50 or 100 char random passwords, but still insulated against attacks with endless streams of input data - it is acceptable to reject 10 000 char passwords as a hostile input designed to tie up server resources.

I said nothing at all about what the minimum password length should be, and that's deliberate, it's a separate kettle of worms.

But ok: I'm also not a fan of measures such as "password entropy" or "must contain at least one from column A and one from column B". Subjectivity, naive use and changing attacks have given these a bad reputation, often deserved. Password length is not subject to such changing moods.

The parent posts comment, "A decent minimum password length, without any funky requirements, just the minimal length" is fine by me. I didn't want to add to that statement on the topic.

With all the rules in the world, some people are going to have relatively weak passwords, and we cannot entirely eliminate that. But we can also allow and encourage strong passwords by - as an easy first and minimum step - removing deliberate misguided impediments like max lengths and disabling paste.

I think that you misunderstood. What I want is that the password can be 100s of chars long, if the user so chooses. i.e. no noticeable maximum length.

I said nothing at all about minimum password lengths, and that's deliberate, it's a separate kettle of worms.

I think the only way this can happen is zero-knowledge password proofs, i.e. browsers implement a mechanism by which password fields submit a proof that the user has the password, rather than submitting the password. This way the server can only verify the password if they've implemented the proof system correctly, and they can't leak the password because they've never had it.

The basic idea is, the server gives a unique nonce with the password form. The user enters their password. On form submit, the browser stretches the key space of the password using a slow hash, then uses the digest to generate an asymmetric key via a referentially transparent algorithm (no random salts). Then the browser prepends the URL (obtained from HTTPS) to the given nonce (to prevent man in the middle attacks). The browser then checks to see if it has seen this nonce before and displays an error if it has (to prevent replay attacks--this forces servers to generate new nonces, although the browser can't force them to verify that the nonce that is signed later is the same one they sent). Finally the browser uses the key to sign the nonce, and sends the signature to the server. The server uses the public key (which was generated in the same way and given to the server at sign-up) to verify that the user has the password.

I love the idea of zero-knowledge password proofs. Others can chime in on the approach you've proposed, but I have a more practical concern about developing critical mass.

How do you break through the chicken and egg problem of not enough users using or not enough browsers supporting this capability?

Find a large user who feels this is a valuable feature and have them adopt it.

Governments are one such large customer.

Vendors, faced with multiple customers requesting a feature, but with slightly varying specifications, will tend to seek a mutually acceptable spec.

If it's a field on inputs of type password, all you'd get is something like:

Browsers that support the password-nonce argument sign as I described. Browsers that don't support it pass through the password and the server performs the ZKPP key generation (this is no worse than the current system of hashing passwords). So servers can implement this immediately without worrying about breaking in non-supporting browsers.

After adoption by a few major sites, browsers can add a warning that the server didn't send a password nonce and the password will be passed to the server so the user has to click "Okay" before it gets submitted. This can be escalated to more severe messages to pressure more sites to comply.

I'm waiting for other people to tell you to implement this, but without JavaScript.

Implementing it in Javascript would defeat the entire purpose. The point is for the browser to implement it as a supported field on input tags of type password.

- Being able to prosecute any company that stores passwords in plain text

And the death penalty to any company that emails you your plaintext password (and even worse, the email tells you to "protect your password").

You don't want to restrict on any password aspect but this:

Is the password known?

Any sort password is know. There are lists of millions of known passwords.

Better would be to get away from passwords entirely.

NB: I've been checking the xkcdpass utility (available on Debian). Generated 50 sets of 100,000,000 passwords each, comprised of six words (the default), then sorted these uniq, and counted the output lines.

Any duplicates would result in fewer than 100,000,000 lines.

All fifty trials had no dupes.

Took most of a week to run that, on an older box :)

Reply on news.ycombinator.com