Hacker News Reader

Comment by ilovetux | Hacker News Reader

I think that a lot of the problems that are inherent to passwords might be mitigated by not allowing the user to choose a password. A strong, randomly generated password being given to the user and changed periodically would almost force the user to use some sort of password manager.

If this were adopted industry-wide (a big ask, I know) then users would be able to use the familiar "enter username and password" system while being protected from common mistakes/misjudgments.

View on HN

'Ugh, this site forces me to remember this shitty password, Guess I'll go to the competitor'

This kind of friction is exactly what troy is talking about.

As opposed to "Oh, they want a password? I guess I'll use the same one I use for every other website."

I agree that the business makes the decision, growth is the top priority and friction reduces growth, but in reality this is how most of the world already works. If you rent a hotel room you don't get to provide your own key and if you lose their key then you must prove who you are to get another one issued.

In the end there must be some compromise between growth and responsibility. If a company cannot grow responsibly then we end up with Facebook all over again.

Your hotel example is pretty absurd, because there's no friction involved in carrying around a hotel room key.

There is significant friction involved in memorizing a long password. So no, it's not "how most of the world already works".

I will admit that it's not quite equivalent, but there was a learning curve that happened when hotels switched from metallic keys to magnetic keycards. I don't think that it's absurd.

I guess a more direct example would be an employer trusting you with the combination of a safe. You would need to remember the combination which presumably would be changed periodically.

The point I think I'm trying to make is that it's rare for a business to leave the responsibility on the consumer to secure the property of that business whether it's access to a server, a hotel room, or a safe.

If it's a company safe? Well of course that's the employer's decision.

A better example would be a safe deposit box or storage unit with a combination. Where you are accessing your account so to speak. There you can pick the combination yourself in most cases.

Password re-use is bad, true.

But it is frictionless for the user. The entire point of the article is that trading friction for security isn't going to happen in most businesses.

> A strong, randomly generated password being given to the user and changed periodically would almost force the user to use some sort of password manager.

or it would force them to click "reset my password" every time they use your service. now your service is only as secure as their email account.

This would be a valid concern, so I suppose that it would take an industry-wide push (which I know is unlikely) to educate users about password managers, but I would argue that if we want to improve upon the password based authentication then it would be easier to educate users if we are using a familiar interface with just one single change.

> now your service is only as secure as their email account.

Surely that was already true?

At that point why not just switch to PKI?

pki is a barrier to entry for most. the user would have to set their browser up to present a unique key pair for each site they use. I think mutual auth is better suited to automated administrative tasks.

but isn't a password manager just as much of a barrier in this context?

I don't believe so, I remember learning about Public Key Infrastructure a while ago. It's one of those things (kind of like git) where there is a steep learning curve up front, but once you understand it seems simple.

A password manager on the other hand is just a place to store credentials. Credentials is a concept that most people understand. A password manager in this context could be as simple as a text file on your desktop (not a great idea), or the one included with your browser (a little better, but make sure you set a master password), but if you want more features there are more sophisticated options available.

Ok lets compare these approaches rationally, especially from a user perspective. If you let the service provider choose/generate the password it might as well generate your keys for you, there really isn't much of a difference. From a credential management perspective there really isn't a difference either between a long non-human readable password and a long non-human readable private key. They basically suffer from the same problem, neither can be used without access to the credential manager. The only "advantage" passwords in that scenario have is that you don't need to sign anything you can just send it to the relying party however when you rely on password managers to input your credentials anyway that manager can manage signing as well right. I'm not advocating to use PKI instead of passwords just that forcing the use of password managers through very complicated long forced passwords has in my opinion not much of an advantage over PKI when both are equally opaque for casual users.

I understand what you are saying, but the fundamental difference here is that for PKI, the browser has to be configured properly as your key pair must exist and the correct public certificate must be used in TLS negotiation. The advantage here is that the password can be copy and pasted into a password form after TLS has been negotiated.

Coupling authentication with encryption has its place, but I would think that it would work better when accessing a service through an app rather than a browser since the app publisher can create unique a key pair and sign the certificate with their own CA and use that for authentication, but in the context of a web app accessed through the browser copy-and-paste beats having to configure your client certificate per domain at least from a "user friction" point of view.

In that case the user would use their e-mail as password manager.

Which might be an improvement or might not.

Reply on news.ycombinator.com