71–80 of 520 posts
The worst offender I have seen in the wild is treasurydirect.gov. The password must be click in on an online keyboard, and they do not allow password managers to enter the passwords. Screenshot here: https://en.m.wikipedia.org/wiki/TreasuryDirect
Imo one key point is missing: Don't give users the option authenticate via Google or Facebook. While it may be convenient at signup, it creates an unneeded dependency and confusion if you forget how you log into a certain site.
Lots of dev tools do this with github, too. The idea of a web-wide sso is a bad one.
You could, for instance, let people have a public key to identify themselves. Your browser or other client could automatically submit your chosen key for you (or expose a button for you to submit it), then there's a challenge and response, and you're logged in. Your account details are stored with the public key as the id.
There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.
Earlier quoted context omitted.
So everyone is happy with depending on a password manager? Because having 100 different passwords and having to rotate those isn't going to happen any other way.
There is no reason anyone needs 100 different passwords and/or those passwords to rotate. This is terrible advice, you don't need it and you shouldn't do it. As of current, haveibeenpwned hasn't found any breaches connected to my current email address, which I switched to around three years ago. Which is to highlight: Most breached password data is really, really old . A surprising number of breaches come via an emai…
This is also true for complex password patterns. It's so dumb. Don't make me use special characters, period. Otherwise it's going to be a dollar sign at the end, which is a common pattern, so now the theoretical complexity gains are vastly reduced.
It's also frustrating when I've entered more than the required amount of characters (sometimes a lot more) and your stupid form validation still insists I need more character classes. Why exactly? Stop making password rules suck, if they do, I'll assume your infosec department is completely useless.
The worst offender I have seen in the wild is treasurydirect.gov. The password must be click in on an online keyboard, and they do not allow password managers to enter the passwords. Screenshot here: https://en.m.wikipedia.org/wiki/TreasuryDirect
It uses some kind of JS trick to replace usernames and passwords with asterisks, and you end up with all kinds of invalid information stored in your password manager.
Earlier quoted context omitted.
Yeah, federated flows were my guess too. However, the password fields could have been present and hidden in the same page supporting both password managers and avoiding a page transition. And also the hundred other sites that don't need federated flows but think they need to copy this feature as well. Together it's annoying to hit password managers twice for every login.
> However, the password fields could have been present and hidden in the same page supporting both password managers and avoiding a page transition But then you run the risk of your password of being submitted to the wrong portal no? > And also the hundred other sites that don't need federated flows but think they need to copy this feature as well Very true. It seems to be becoming increasingly prevalent :(
There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.
>Password managers can't deal with this, unsurprisingly. I use a password manager too and often wonder about this. Does this responsibility fall on the website's designer/developer or the password manager? In one hand, I'd like my password manager to work on every site too but on the other, being a web developer/designer, I don't want another thing to support. We already have browsers and browser versions, and browse…
Should screen readers be able to handle some unusual pages? Yes. Should websites design for accessibility? Yes.