Websites that split username and password fields onto two separate pages should be blown up. Extremely.
@vwbusguy @mike Well I believe in using cryptography to avoid the need to share secrets with a website. Authenticating to websites the same way they authenticate to us.
At which point cryptographic signatures could fill this usecase without requiring sending forwarding any messages on!
Ofcourse standards would need to be rewritten...
@toe @alcinnz @mike If you want to talk about auth models that people think are secure but really aren't, we can talk about JWT while we're at it. Virtually all JWT are signed but not encrypted, so just need a base64 decode to get all the session data from the cookie. Many don't even bother to check the signature either.
@vwbusguy @toe I think I recall something about the Java API for checking those signatures got broken recently when it was reimplemented in Java, with the exploit being called Psychic signatures.
And yes, I know not all password managers break on this... But some do.
And yes I'm wishing for a WebAuthn, or equivalent, future. Not particularly happy its a JS API though, being the developer of a JS-free browser engine who believes in their cause...
@vwbusguy @toe Lets put it this way: SAML is a workaround for the sorry state of authentication today, its not a solution in-and-of-itself. Though it can be used to deploy actual solutions upon services which haven't implemented them.
Personally I'd prefer not causing any problems for any password managers since those can help transition us to an actual solution, but I can respect people making a different assesment of the situation. Even if it leaves me grumbling.
@vwbusguy Not exactly what I have in mind...
Client computer signs a server-provided nonce & uploads the corresponding publickey certificate signed directly or, crucially for this usecase, indirectly by the webservice. No webservice receives the secret!
Why do we refuse to transition to this future!? Password stores/managers like LibSecret & Bitwarden support it! But webservices which split username & password fields onto their own pages frustrates such tools...
@alcinnz I use KeePassXC and it doesn't have this problem.
@fiskfan1999 @mike AWS has an "all fields on one page" login page.
https://console.aws.amazon.com/console/home?nc2=h_ct&src=header-signin
I don't know why they have the other kind as well. Probably maintained by a different department?
@mike why do they do that? it's a recent trend isn't it?
@mike I agree! Even for the SAML use-case as discussed below, the password field could be present on the first login page, just disabled until after the username is entered.
Then either the user is sent away to their SAML IdP for auth, or the password box lights up to be talked to. This would probably still work with password managers just fine. Which of course you're using, because you're a good human.
@yojimbo it was having to switch in and out of my password manager twice in a row for the same site that precipitated this little rant, heh.
@mike 1Password can fill in multi-page logins for me. Can't speak for Bitwarden because I don't remember using any like that recently ... and I don't currently use any others.
@mike I had to create a password for a website that had to be forty characters or more 🤖
@mike worse still : sites that hide the password field before you enter the email, and even if your password manager fills it in, clear it when you click next.
@mike Lol. It's as if they never heard of a "form".
@mike I mean when people realize how bad of a single point of failure their cloud-based password manager is, it won't be a problem anymore.
@mike oh I hate them I hate them so much. It's convenient on my phone having fingerprint unlock on password manager but still...
@mike Unfortunately, there are good reasons for it. If the site supports SAML (which is very much a good thing), it needs to know something about your affiliation before redirecting to the right identity provider.