Hacker News Reader

Comment by robert_tweed | Hacker News Reader

No link handy but I'm sure someone recently wrote an open source effective entropy calculator, which avoids either enforcing stupid entropy-reducing, complexity-increasing rule sets, while also preventing anyone using stupidly easy to guess passwords. Others do things like check against a normalised dictionary (i.e., I, 1 or L are all considered the same character). I really don't know why in this day and age of complex software with libraries for even trivial functionality, this practise isn't more widespread. People are still writing dumb complexity rules like it's 1980. This should really be the new "don't do your own crypto".

View on HN

This is a step in the right direction, but down a dead end. Like trying to reach the moon by climbing up a tree.

Taking a step back, what we are doing is essentially: you may choose your own password! But, not really. We are going to tell you what not to. After you try it. And it's not a human, or equivalent AI: it's a (dumb) algorithm.

If you are going to let someone choose a password, ask yourself: why? Is convenience that much more important than security? Putting, what many people will perceive as, onerous constraints on the passwords greatly reduces that convenience. But users will still try to make it as low entropy as possible, so security suffers, nonetheless.

Or is security so important, to hell with convenience? Then why not just generate a PW for them? Here, print this out, since you were going to, anyway. Click "save this password", since you were going to, anyway.

Cut out the middle man and save everyone time.

Now, instead of forcing your users to do the try-to-cheat-the-entropy-algorithm dance, you can show them what a good password can look like. String four words together: happy (or less annoyed) users, good entropy, happy admins.

I agree entirely. In fact, this is precisely how passwords were implemented in a project I've only just finished.

In addition to the frustrations you've outlined, consider a further case where a user's username is their email address (this was true in the project I mentioned). How is the user most likely to behave in this scenario? Are they going to take the time to generate a new password that satisfies your constraints, or are they going to keep things familiar and use the same password that they use for their email? Afterall, the usernames are the same - so why not keep things easy to remember? Well, I'm sure that's convenient, but I absolutely DO NOT want your email password, even bcrypted/&c., in my DB. No thanks.

Clearly, then, the best choice is to generate something for the user; something that they can reset using a classic 'forgot password' system, but which they never have to define themselves. Four diceware generated words, plus spaces, each no longer than two syllables, seems to do just fine.

you're thinking of Dropbox's zxcvbn [1] demo [2]

[1] https://github.com/dropbox/zxcvbn

[2] https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.ht...

> On window.load, [..], it'll fetch zxcvbn.js, which is [..] 700k (330k gzipped)

As a client side solution, that download size seems excessive for a password strength meter.

I understand it contains a dictionary of passwords but that is larger than most JS frameworks. Perhaps a server-based XHR-based solution would be better.

Think about what you've just said. How insecure is sending the password (hopefully over an HTTPS connection!) to a remote server?

How else do you allow someone to use a password to login? I suppose you could run the hash locally if they have JavaScript-- but if they don't, then what? (Edit: Good point, all the hash achieves is that the user's entry isn't sent in clear text -- of course, the hash itself then becomes the password for the purposes of authorization.)

Running a hash locally is equally useless. You've effectively turned the hashed value into the password itself, achieving nothing.

There are secure key-exchange schemes that don't require sending over the raw password, but this isn't an example of one.

Just about every signup and login form does this (and yes preferably over TLS only). What is the problem with it?

The alternative is browser-side encryption of the password before sending but that will get @tptacek rightfully punching you in the face for even mentioning it.

It's only for the signup page so that really isn't a problem.

"This should really be the new "don't do your own crypto"."

oauth / openid for the win

Unless your companies "secret sauce" is user authentication and management, you probably shouldn't be doing it.

You still almost certainly need to implement a backup system. It is rarely a good idea to force a new user to enter his facebook/google/ms credentials to use your service. Even if 99% of your potential userbase has such credentials they may not want to connect them to your service.

That's even before getting into the question about whether or not such systems make it more likely that users will fall to phishing attacks by conditioning them to enter their credentials somewhere other than the website where they were issued that they went to directly.

Using OAuth also doesn't give you a free pass. Plenty of apps/sites/organizations mess up OAuth implementation, and OAuth doesn't solve things for corporate/enterprise users either.

It's also not suitable for certain demographics, which puts you back at square one (rolling your own).

Reply on news.ycombinator.com