7 ms·

My (probably unpopular) opinion is that passwords should be randomly generated by the service, and not possible to change to a user-selected value. If you allo

by ryan-c 9y ago

My (probably unpopular) opinion is that passwords should be randomly generated by the service, and not possible to change to a user-selected value. If you allow people to choose their own passwords, the vast majority will reuse them, and their account will eventually be compromised via credential stuffing. I recognize that this solution will, at least initially, infuriate people. Letting people opt in to federated auth if they prefer that (I hate services that require it) might make it more palatable.

trevyn 9y ago
For services that generally "stay logged in", why have passwords at all? Just do "magic login link" emails, with some sort of 2FA if you're into that.
- zootm 9y ago
  Isn't the former what Mozilla Persona was trying to provide? A shame that was canned.
  - onli 9y ago
    We built a successor project under https://portier.github.io/ https://portier.github.io/. Alive and kicking :)
- ryan-c 9y ago
  I think "magic login links" are fine for most services. Doing 2FA with that is not feasible though, unless you want to argue that receiving the email counts as "something you know" or that "something you have plus something else you have" counts as 2FA.
  - trevyn 9y ago
    If you have your email protected with 2FA, I think you're covered -- "An unlocked device with an active session" is the thing you have. I think this is actually what's happened -- people now know not to leave unlocked devices unattended, so you basically do 2FA every time you unlock your device, so the device can now stay persistently logged into all services.
- tmnvix 9y ago
  I've considered using "magic login link" emails but greylisting[1] seems to be an insurmountable problem. [1] https://en.wikipedia.org/wiki/Greylisting https://en.wikipedia.org/wiki/Greylisting
  - ryan-c 9y ago
    Generally greylisting is supposed to let future emails through once it establishes that a server will re-send. It should be possible to detect greylisting and warn the user. "Your email provider temporarily rejected our email to you. We will retry in a few minutes. If this happens persistently, please (check our guide for your provider, $MAJOR_PROVIDER|contact your provider) to figure out how to whitelist our login emails"
jasonkostempski 9y ago
Everyone would have to get on board with that at the same time. If the user is forced to memorize the password your service generates, they'll use it for everything else anyway.
- ryan-c 9y ago
  How many people are going to memorize something like this? fvtwt gvltv wlbth wgwdh njfnn
u801e 9y ago
> My (probably unpopular) opinion is that passwords should be randomly generated by the service, and not possible to change to a user-selected value. I would rather have a client side TLS certificate that's generated by the website I'm trying to log into when I create an account with them. You could still keep the username and password application level log in in addition to the certificate to get a second authentication factor.
- ryan-c 9y ago
  Did you ever use StartSSL? They did TLS client auth and it was surprisingly terrible.
  - u801e 9y ago
    I never had the opportunity and, according to their website, they closed last month. Since I can't try it out myself, what was so bad about it?
  - commandlinefan 9y ago
    TLS implementations themselves need to get a LOT better about describing error conditions before client certs will ever be a viable option for actual user authentication.
    - u801e 9y ago
      Could that be something that a web browser or other client could translate to a more user friendly message?
nine_k 9y ago
The service should not ever get hold of an unencrypted password.
- icebraining 9y ago
  For a website, that's hard to achieve. You can ship some JS to pre-hash the password, but an attacker that can read unencrypted passwords from the server can probably also modify that JS code to send the original password to them. If you have clients that run locally (and for which the updates are hopefully signed offline), I do think that approach is sensible.
  - nine_k 9y ago
    Not storing passwords on the server removes some of the incentives to break into the server, and makes a quick and covert heist impossible.
    - ryan-c 9y ago
      If the server requires me to send it the md5 of my password (for example), it still has to store something to validate the password, which can then be cracked.
      - nine_k 9y ago
        Sure, the server should expect a bcrypt hash, and only store a bcrypt hash. OTOH maybe requiring client to compute the hash is sometimes too drastic. Sending the password to the server via a properly encrypted channel (https) may be fine, provided that the server never stores it, and just uses it to compute a hash for comparison. Then my original point does not hold.
mrep 9y ago
That pretty much requires you to use something like 1password which if hacked (your error or theirs (who knows how good some random companies security is)) then you are completely screwed as all of your accounts are now compromised. To make matters worse, you don't know any of your passwords so you cannot even log onto any of your accounts to change them (this is also a big problem if you have a customer service problem as it will lock you out of all your accounts). I'm not a security engineer but this sets off all of my internal alarm bells when my entire identity relies on the security of 1 unrelated company that I pay a few bucks a month for.
- ryan-c 9y ago
  > That pretty much requires you to use something like 1password That's the point. > you don't know any of your passwords so you cannot even log onto any of your accounts to change them Nearly every service allows email-based password reset. > I'm not a security engineer but this sets off all of my internal alarm bells when my entire identity relies on the security of 1 unrelated company that I pay a few bucks a month for. For most people, their entire identity relies on the security of their email address plus some information they shared on Facebook.
nickjj 9y ago
If the password is randomly generated by the service then you need a way to present the password to the user in plain text. I think you're trading 1 problem for another.
- always_good 9y ago
  If your users are getting pwned because they reuse their easy leaked passwords on your service, then that's the real world adversary. Also, all passwords appear in plaintext at some point. Even when sitting in a type="password" field that was autofilled by your uber secure password manager. The main problem is that this solution is just pointlessly bad UX for most sites. But worth it (or something like it) if your users are losing real money.
- ryan-c 9y ago
  That's fine. Storing passwords in plaintext is the problem. It could be displayed as selectable/copyable but not visible text by default with a "reveal" button to prevent shoulder surfing.
  - nickjj 9y ago
    Yes, that "show once" feature works well for keys / tokens because developers usually use them right away in their app so it doesn't get lost. But for a regular person, you may put them into a deadlock if you generate a secure random 16 character password with 1 chance to remember it. Just imagine dropping "K@!G-:)XTqqy<44x" in front of a regular user telling them they have 1 shot to store this password before it disappears forever. Most people who aren't into tech are just going to give up and leave IMO. It took me like 5 minutes to explain case sensitivity to my dad who knows computers well enough to do day trading but calls me up for things like "why can't I login to my email?". Asking him to type in a password like that would probably give him a stroke. Emailing it to them in plain text is also not a reasonable solution. Not only is it wildly insecure, but you would be surprised at how many people don't know how to copy / paste text.
    - ryan-c 9y ago

by ryan-c 9y ago

trevyn 9y ago

For services that generally "stay logged in", why have passwords at all? Just do "magic login link" emails, with some sort of 2FA if you're into that.

zootm 9y ago
Isn't the former what Mozilla Persona was trying to provide? A shame that was canned.
- onli 9y ago
  We built a successor project under https://portier.github.io/ https://portier.github.io/. Alive and kicking :)
ryan-c 9y ago
I think "magic login links" are fine for most services. Doing 2FA with that is not feasible though, unless you want to argue that receiving the email counts as "something you know" or that "something you have plus something else you have" counts as 2FA.
- trevyn 9y ago
  If you have your email protected with 2FA, I think you're covered -- "An unlocked device with an active session" is the thing you have. I think this is actually what's happened -- people now know not to leave unlocked devices unattended, so you basically do 2FA every time you unlock your device, so the device can now stay persistently logged into all services.
tmnvix 9y ago
I've considered using "magic login link" emails but greylisting[1] seems to be an insurmountable problem. [1] https://en.wikipedia.org/wiki/Greylisting https://en.wikipedia.org/wiki/Greylisting
- ryan-c 9y ago
  Generally greylisting is supposed to let future emails through once it establishes that a server will re-send. It should be possible to detect greylisting and warn the user. "Your email provider temporarily rejected our email to you. We will retry in a few minutes. If this happens persistently, please (check our guide for your provider, $MAJOR_PROVIDER|contact your provider) to figure out how to whitelist our login emails"

jasonkostempski 9y ago

Everyone would have to get on board with that at the same time. If the user is forced to memorize the password your service generates, they'll use it for everything else anyway.

ryan-c 9y ago
How many people are going to memorize something like this? fvtwt gvltv wlbth wgwdh njfnn

u801e 9y ago

> My (probably unpopular) opinion is that passwords should be randomly generated by the service, and not possible to change to a user-selected value. I would rather have a client side TLS certificate that's generated by the website I'm trying to log into when I create an account with them. You could still keep the username and password application level log in in addition to the certificate to get a second authentication factor.

ryan-c 9y ago
Did you ever use StartSSL? They did TLS client auth and it was surprisingly terrible.
- u801e 9y ago
  I never had the opportunity and, according to their website, they closed last month. Since I can't try it out myself, what was so bad about it?
- commandlinefan 9y ago
  TLS implementations themselves need to get a LOT better about describing error conditions before client certs will ever be a viable option for actual user authentication.
  - u801e 9y ago
    Could that be something that a web browser or other client could translate to a more user friendly message?

nine_k 9y ago

The service should not ever get hold of an unencrypted password.

icebraining 9y ago
For a website, that's hard to achieve. You can ship some JS to pre-hash the password, but an attacker that can read unencrypted passwords from the server can probably also modify that JS code to send the original password to them. If you have clients that run locally (and for which the updates are hopefully signed offline), I do think that approach is sensible.
- nine_k 9y ago
  Not storing passwords on the server removes some of the incentives to break into the server, and makes a quick and covert heist impossible.
  - ryan-c 9y ago
    If the server requires me to send it the md5 of my password (for example), it still has to store something to validate the password, which can then be cracked.
    - nine_k 9y ago
      Sure, the server should expect a bcrypt hash, and only store a bcrypt hash. OTOH maybe requiring client to compute the hash is sometimes too drastic. Sending the password to the server via a properly encrypted channel (https) may be fine, provided that the server never stores it, and just uses it to compute a hash for comparison. Then my original point does not hold.

mrep 9y ago

That pretty much requires you to use something like 1password which if hacked (your error or theirs (who knows how good some random companies security is)) then you are completely screwed as all of your accounts are now compromised. To make matters worse, you don't know any of your passwords so you cannot even log onto any of your accounts to change them (this is also a big problem if you have a customer service problem as it will lock you out of all your accounts). I'm not a security engineer but this sets off all of my internal alarm bells when my entire identity relies on the security of 1 unrelated company that I pay a few bucks a month for.

ryan-c 9y ago
> That pretty much requires you to use something like 1password That's the point. > you don't know any of your passwords so you cannot even log onto any of your accounts to change them Nearly every service allows email-based password reset. > I'm not a security engineer but this sets off all of my internal alarm bells when my entire identity relies on the security of 1 unrelated company that I pay a few bucks a month for. For most people, their entire identity relies on the security of their email address plus some information they shared on Facebook.

nickjj 9y ago

If the password is randomly generated by the service then you need a way to present the password to the user in plain text. I think you're trading 1 problem for another.

always_good 9y ago
If your users are getting pwned because they reuse their easy leaked passwords on your service, then that's the real world adversary. Also, all passwords appear in plaintext at some point. Even when sitting in a type="password" field that was autofilled by your uber secure password manager. The main problem is that this solution is just pointlessly bad UX for most sites. But worth it (or something like it) if your users are losing real money.
ryan-c 9y ago
That's fine. Storing passwords in plaintext is the problem. It could be displayed as selectable/copyable but not visible text by default with a "reveal" button to prevent shoulder surfing.
- nickjj 9y ago
  Yes, that "show once" feature works well for keys / tokens because developers usually use them right away in their app so it doesn't get lost. But for a regular person, you may put them into a deadlock if you generate a secure random 16 character password with 1 chance to remember it. Just imagine dropping "K@!G-:)XTqqy<44x" in front of a regular user telling them they have 1 shot to store this password before it disappears forever. Most people who aren't into tech are just going to give up and leave IMO. It took me like 5 minutes to explain case sensitivity to my dad who knows computers well enough to do day trading but calls me up for things like "why can't I login to my email?". Asking him to type in a password like that would probably give him a stroke. Emailing it to them in plain text is also not a reasonable solution. Not only is it wildly insecure, but you would be surprised at how many people don't know how to copy / paste text.
  - ryan-c 9y ago