5 ms·
Controversial opinion: Username and password is perfectly fine. To provide an example that most people here are probably comfortable with: An SSH key is effect
by RadiozRadioz 2y ago
Controversial opinion: Username and password is perfectly fine.
To provide an example that most people here are probably comfortable with: An SSH key is effectively a really long password with cryptographic properties. It's a single factor, one thing, that you use to complete a challenge for the server. We are fine to use SSH keys as our only authentication factor for servers, with IP whitelisting where security trumps convenience; why should we feel uncomfortable using long passwords as our only authentication factor for websites, with opt-in MFA when security trumps convenience?
Instead, websites enforce terrible 8-20 character passwords with a recipe of strict requirements to help crackers, and a download of the flavor of the month authenticator app that quickly becomes burdensome and annoying.
Why does my library think they're Fort Knox and want me to get an authenticator app? The tech is fine, but its universal forced application bugs me. It's like those campaigning for enforcing MFA everywhere never considered that different users have different risk appetites/tolerances.
The problem with passwords comes when humans mismanage passwords and pick bad ones. Passwords themselves are fine.
- jrochkind1 2y agoAh, so the problem is the HUMANS! This is great, because all we need to do is switch out the humans.
- deleted 2y ago[deleted]
- wlesieutre 2y agoAn SSH key isn’t exactly a long password since the service you use it for can’t leak your private key in a security breach
- bruce343434 2y agoThe password isn't leaked, a hash of the salted and peppered password is the only thing in the database (+ the salt, and the pepper elsewhere).
- cassianoleal 2y agoAssuming it's implemented that way. Which is a big assumption.
- bruce343434 2y agoAs the main post was written in the voice of a knowledgeable developer picking a login flow, I assumed so indeed.
- lesuorac 2y agoI still cannot understand why mutual TLS never took off anywhere besides Gov [1]. You know how much more convenient it is to just open a browser and go to a webpage and already be logged in? [1]: https://en.wikipedia.org/wiki/Common_Access_Card https://en.wikipedia.org/wiki/Common_Access_Card
- bqmjjx0kac 2y agoWouldn't that broadcast a stable identifier to every site you visit?
- lesuorac 2y agoIsn't that desirable? Safari (Apple), IE/Edge (Microsoft), and Chrome (Google) all operate their own ad networks. I'm sure they'd love their own version of X-UIDH [1]. [1]: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
- fragmede 2y agothat's precisely why it's not desireble
- hinkley 2y agoMutual TLS was necessary but a giant pain in the butt for an app I worked on that needed to do over the air updates over WiFi. Getting it working across all of the moving parts was a significant part of the overall effort for the OTA part of that project. OCSP existed back then which helped but I don’t know if stapling had been widely implemented yet.
- RadiozRadioz 2y agoYes, I deliberately didn't say it was _exactly_ a long password. I was more trying to get across the single-factor side of it. In any case, if the service handles passwords properly and the user generates one password per service (both wild far-out concepts unfortunately), leaking the salted hash would not matter.
- wlesieutre 2y agoAgreed, but it’s nice to not have to trust a service to handle passwords correctly
- deleted 2y ago[deleted]
- pieter_mj 2y agoHow much does the recipe of strict requirements limit entropy of the password or enhance its predictability (both are somewhat related)? More of a problem is password reuse for multiple sites, which is impossible when using SSH keys.
- fragmede 2y agoNot to admit to poor security practices in public, but I don't generate different ssh keypairs for every server I log in to. If each keypair represents one password, and we're never supposed to reuse a password, I'm in trouble.
- rlpb 2y ago> We are fine to use SSH keys as our only authentication factor for servers… Are we? True 2FA for ssh keeps getting easier. There’s FIDO2 support now for example. The gold standard includes 2FA and I don’t see why that shouldn’t continue filtering down to common practice, just as has already happened with ssh keys.
- aseipp 2y ago> An SSH key is effectively a really long password with cryptographic properties "An SSH key is basically a really long password, but also at the same time it's not a really long password, and you interact with it entirely differently." OK. Modern password managers make long passwords vaguely "look like" SSH keys much in the same way a truck might vaguely "look like" a train. But they only achieve this by taking over the creation and use of the password entirely, even going so far as to tie them to origins in your browser, to prevent them from being inserted into a hostile webpage (phishing attacks still work just fine.) So they're not really passwords anymore, just bearer tokens. But bearer tokens are not SSH keys, anymore than a password is an SSH key. The SSH analogue to login passwords are SSH passwords, not SSH keys. And nobody uses SSH passwords anymore for the same reason people don't like web passwords, today (at least on the web 90% of the time you can email reset.) Even the follow up methods like credential stuffing are identical; typing in a password to a hostile SSH server will absolutely result in that username+password being spammed at every possible service as a brute force method. The reason this method isn't still popular today is because collectively ~everyone started using keys like 20 years ago for everything. But credential stuffing and phishing are still massive problems for the web.