Follow

Websites that split username and password fields onto two separate pages should be blown up. Extremely.

@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.

@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...

@alcinnz @mike you just described SAML. The website never gets the secrets and the auth with the IdP is generally signed and encrypted. The website never gets the password in any form.

@vwbusguy @alcinnz do you guys actually need me around for this fun conversation?

@vwbusguy @alcinnz @mike Yes and no. If you use SAML with password-based authentication, you're still sending your password to the SAML IDP.

It would make sense to eliminate even that need by using pubkey-based auth instead. That's how I understand @alcinnz response above.

@toe @alcinnz @mike The SP never gets the password. I was using overly generic terms. The IdP gets with credentials which can be any number of things - password, cert, IP, webauthn + MFA, etc. The SP doesn't get any of that. Just the signed/encrypted attributes after authentication.

@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 @alcinnz no, actually I don't want to talk about auth models thanks.

@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...

@toe @vwbusguy @alcinnz I spent last night writing code to drive an i2c device from NetBSD using ioctl and yet somehow I'm the one here wanting to flush a bunch of nerds' heads down the toilet.

@mike @toe @alcinnz I managed the IdP stack for my past two previous employers (and gave talks on it) and I wanted to flush my own head during that time.

@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.

@alcinnz @toe SAML itself isn't the problem - it's a very mature, well defined protocol, but there are a ton of absolutely abysmal implentations of it. Managing all the custom 3rd party SP hackery was the most maddening part of the experience.

@alcinnz @toe And I'm with you on webauth. There's so much unrealized potential there.

@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...

@mike using the #aws website the seperate password page never got recognized when I used #brave so I had to copy paste the password every time (which has amazing potentials for security breaches) but I switched to #firefox which recognizes this website correctly.

@fiskfan1999 @mike AWS has an "all fields on one page" login page.

console.aws.amazon.com/console

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 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...

Sign in to participate in the conversation
Chinwag Social

Consider this a friendly, local pub. Make yourself at home, bring your friends, have a good time! Meet new people, have a laugh, enjoy the ambience, and the Oxford commas.