Just like you have new NIST recommendation about not enforcing complexity. Big customers on the other hannd have it as number 1 requirement when they buy. So even if I wanted to have no complexity enforcement, I had to build in one...
There are also some more obvious smaller examples, like expanding/collapsing an accordion menu.
It makes sense because adding an upvote is the same as adding other form data to a database semantically so really should be treated the same way.
Can someone please tell SAP?
They’ve just discovered that displaying the URL bar is more secure than not.
You want to expose the functionality to make a drastic change on some resource, identified by a string, to the user. Users want this functionality for good reason. It's not reversible, for legal or security reasons. This is a change that could easily destroy the user's company or cost it millions of dollars.
Text specifying what they're doing is insufficient, as users just click through without verifying. Even a checkbox does nothing to make them pay attention. Even an input where they specify what resource they're performing this action on isn't enough, as two users have reported that they just copied and pasted the id of the resource instead of typing it in.
Sometimes you want to break the consistent interface. I don't think "verify that you typed in the password you wanted to for some shitty small company's website" rises to that level, but there are legitimate reasons to drastically increase the cognitive load involved in simple actions by breaking the uniform interface.
The purpose of this input field isn't specifically to make the user type. It's simply to ensure they know the name of the repository they're deleting.
Sure Github could (and do) display the repository name; but users are accustomed to just hitting next without reading written text.
Input boxes (as opposed to buttons) requires user attention because the user has to know what content to place in the input field. Copying and pasting still meets this requirement as the user has to scan for the repository name (i.e. read) then copy and paste that into the field.
This is why you should (almost) always offer undo for any action that would require a confirmation.
A good balance would be Confirmation -> a window of time (5 seconds - 30 days) when undo is possible -> a slightly hidden menu for irreversible confirmation.
You might be able to inspect the code of an extension, but it is less straightforward and easy compared to a simple userscript. Plus, with a userscript, there is no risk of the extension author turning malicious and updating it with malware, even if it was clean at one point.
My rule of thumb is using userscripts to modify websites' behavior, and using extensions to modify the browser's behavior. (At least that is the case for Firefox 56: Firefox Quantum and Chrome limits extensions from modifying the browser much; often they are little more than glorified userscripts.)
Trivia: Shift-Ins actually predates Ctrl-V :-)
$0.value = 'hunter2'
I use that in reverse when I can’t remember a password. Get the value from input element gives the browser remembered passwords.
Works on other peoples machines too. If you wanna steal remembered passwords.
That’s how chrome extensions steal passwords. Just sayin.
So, consider this an anti-debunk.
(Can they steal Basic-auth passwords, though?)
Obviously autofill is nicer, but that works even for non-browser apps, so it's nice to have.
Presumably for making it more secure
So that kind of explains why it’s done. It’s a misinformed cargo cult.
I think “protecting” against attacks (and/or accidentally leaking password details) from these kind of sources has to be a big part of the reasoning that has lead so many big sites to make their login experiences so insanely horrible.
There must be a tracker network or big consultant out their that popularized these kinds of techniques and marketed them as a “low hanging fruit defense in depth best practice” ...
Such an amateur-hour mistake: https://goldmanosi.blogspot.com/2012/06/forcing-people-to-us...
Even with the security risks I prefer email login. Logins are in 2 categories: a) stuff I don’t care if it’s compromised. Basically forum memberships, preferences on various sites such as retailers storing a shipping address but no payment details. b) Important things such as my email account.
For category a) sites (hundreds) I use a crap password that has been owned already. It’s 5 chars and the same on most sites. It’s been in pwned dbs for years. I can’t be bothered to use a person manager if it’s more work than 5 keystrokes to do on any platform.
For category b) sites (say ten or something) I use long unique passwords and 2FA.
Obviously it’s better to put everything in b), but I’m lazy. So as a good second best I take good care of the important passwords.
At least the email address can be easily changed when needed, whereas most sites don't allow changing the user ID.
Similarly my banks issue me my website user strings.
Why do so many website permit users to choose? Forcing the user to write-down their assigned designator might lead to better security, too, since they would seem at that point more open to writing-down a strong password.
I also much prefer it to the previous way e.g. Office365 worked, where once you'd tabbed away from the email box, they'd detect you needed to be redirected and send you off, whilst most people had begun typing their passwords.
And you'd have to account for all those tricky race conditions happening there
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 :(
Pisses me off too
It frustrated everyone.
Since we've implemented the stepped process (and made other changes) complaints have all but disappeared, and the number of failed sign in attempts has been significantly reduced, successful logins has increased slightly, and overall login attempts dropped.
It's not perfect, but all indicators are it's better than a screen full of options - it allows us to guide users to the correct action.
Sure, it can still be annoying, but less so than what it was.
But! the "screen" is fake. the password field exists and is visible to the password manager (but not the end user) right off the bat, so it doesn't disrupt them.
But the user experience is extra poor, because they do not honor the Accept-Language header, but insist to use the local language of your public IP address. When travelling that can often be a language you don't understand. And when travelling you often get an extra security step, because they haven't seen you in that country before. Extra painful in a language you don't understand.
Disclaimer: I use Cookie Autodelete and Firefox containers. So they get a bit less info about me than about the average user. But ignoring Accept-Language makes no sense to me. Pretty unlikely the user does not understand the language of the browser but the local language of the IP address.
Besides, I have difficulty believing that this is a common problem. I have never seen a user whose OS was configured to a wrong language. Even if they have zero computer knowledge, they just ask someone else to fix it as the first thing. Computers/smartphones are already scary for technophobes; they wouldn't even touch them when they are in a language they don't understand.
This is especially irritating for VPN users as it is not just a problem when traveling, but all the time. I essentially gave up on hoping to get Google pages in a language that I understand. However, they made the situation worse in the past year: even if I use my country's localized Google domain, Google ignores that and gives me results according to my IP: websites from a different country about a possibly irrelevant subject, in a language I don't understand.
> This is why we went with a stepped process. [..] It frustrated everyone.
> Since we've implemented the stepped process (and made other changes) complaints have all but disappeared
That way, those that use password managers could still continue so (as it would check and see that yes, password flow - or whatever), but for others, it would do something else.
Consider a user starts typing an email address, when do you send out the first async request to find out what authentication flow is required?
On each onChange event, first time the email is valid, would have issues that your email is firstname.lastname@example.org, but email@example.com is already valid, so you're probably going to debounce the call by a few hundred ms.
What if the user makes typos, or if they are typing in the email very slowly, and so on.
You might say it doesn't matter, just don't show any UI feedback until its valid, or keep refreshing the current status, but the problem is your control flow is decided by the email that's typed in. You want to redirect certain users to an SSO page, others to type in their passwords, and so on. firstname.lastname@example.org might need a different authentication flow than email@example.com, which are both valid addresses.
Another choice is the onBlur event, but this becomes clunky. Think about when it's triggered and how you would incorporate this into a nice UX, I don't think it's possible.
The inversion of control, giving the user time to fill the form in, and press an explicit "Ready, I've typed my correct email in, what's next?" button, makes the flow easy to code.
I hope this helps.
This can't be a large majority. I only ever hear complaints.
Whats wrong with the suggested way (Harvest example) of having both on the same screen and letting the user choose
I wish password managers would become popular with non-tech people already. I can't wait for a day where there's just a "Sign in manually" link for the few people that manage to remember their 1200 usernames/passwords. Password managers shouldn't need to rely on autofilling inputs at all.
It doesn’t do well with banks that think they are being clever though.
Password managers have already figured out how to support this transparently, so it's a non-issue anymore... Including even Chrome's built in manager, which is not exactly cutting edge. If yours can't cope then it's a sign that your software isn't being actively maintained very well.
Still annoys me - a classic example of offloading the costs of technical decisions on the user, even if those costs are "just" mental energy and a page load. At the very least, if you feel you need to do this, make the login pages very, very lightweight. One I log in to daily has huge background images that are utterly, stupidly useless, wasteful, annoying and for some reason uncacheable.
Split logins are very useful for federated auth, as well as for supporting different kinds of multi-factor auth.
I agree you can achieve this by other means, but services may have their own reasons for doing it this way.
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 browsers and browser versions in specific platforms to keep track of. Do I want another layer of something to keep track of?
Should screen readers be able to handle some unusual pages? Yes. Should websites design for accessibility? Yes.
Password managers aren't "Another thing to support" but "The only secure way to do passwords"
If your user can remember their password, they also likely: reused it elsewhere, have some pattern to it or minor changes that could be figured out from a email search in any password database, made it simple enough to be not secure.
I think this has to be highest benefit easy-ish thing you can do for someone to aid their computing lives in 2019 ...
Everything sites can do to help users undergo this transition would help them in the long run ...
The big password manager implementations need to do better as well — I don’t understand why iCloud Keychain doesn’t support generating random passwords that conform to the (horrific) password complexity checks you see out there in the world sometimes ... those sites are wrong to have such a broken feature but there are enough such broken sites out there that a clean workaround is needed on the password manager side ...
It would also be nice to have a solution for security questions built in — my solution is an OpenSSL command line for the random password generation and shared notes in which I record security questions and answers for sites. It’s better than actually providing real answers to security questions at least ... support for this functionality should really just be built into my password manager — the alternative likely thing is that a user will use actual answers to security questions for password reset all across the internet and this is not a thing the password managers should support their customers doing ...
Also, let's admit it, unless you do something really crappy like remove copy-paste, forms don't exactly "not work" with managers. Most of the time, you don't have to do anything special and it would work. Some just take a bit more time because you have to cop-paste it and not autofill. But people who are already using pw managers don't just stop using it (or start memorizing their passwords) because one site can't be autofilled. They just copy paste it, at worst, they manually input it while looking at the password from their pw manager of choice.
My line about "supporting" it is a bit off. I used the wrong words. It goes to say that you should support it. Again, you have to do something really out of your way to completely block off password managers from your forms so really, I think the norm is that they support it. My thought goes more along the line of whether I should be the one to adjust when the form works on some pw manager but not on another or when the pw manager can handle other sites properly and not mine. "Working" and "handling" here means it can be autofilled (most of the time).
Sites that want to display readable pages don't have to work on compatibility with Reader View; they can just provide readable pages. I use Reader View mostly to work around sites' intentionally user-unfriendly design patterns (articles unnecessarily split across multiple pages), and only occasionally to work around presumably unintentionally bad design (Kill Sticky does most of that work for me). To the extent that that's true, sites are likely to be interested in being less, not more, compatible with Reader View.
Maybe you have a USB dongle, and after entering your name or email, you are authenticated. Maybe the machine is trusted for any user who logs in, because it has a USB dongle. Or maybe only certain users, but more than one user is trusted associated with that USB dongle.
Or maybe if YOUR phone is detectable as near by, then you have no 2nd login step.
There are lots of arguments why putting the user ID and password onto a single form is just plain wrong. This isn't the 20th century anymore.
Probably more compelling is that the form can pick up your email domain and redirect to Single Sign On if the domain is known.
The right way to do this is have a log in form (one or two pages - doesn't matter) and a separate create account form. You can try to log into a non-existant account, which will fail in exactly the same way as a wrong password. You can try to create an already existing account, which will result in exactly the same behaviour to the webpage user as creating a non-existing account - a page saying "An email has been sent to the email address <foo>".
It's not an issue if you let users pick their own username. There's simply no way to get around this (apart from assigning usernames). In other cases, usernames being publicly available is a desired feature.
I remember that being a thing for a while, but haven’t built user facing UI systems in a few years.
There's simply no way to get around this if users can pick their own usernames (other than assigning them in an unpredictable manner). In other cases, usernames being publicly available is a feature, not a bug.
You have three choices with a user specified login name. You can:
(1) notify a user why account creation has failed (due to a duplicated login name)
(2) fail silently and have frustrated users leave your account creation page
(3) allow duplicated login credentials
In my mind, (2) and (3) are worse than (1). Since the question regards security practices, obfuscating the login name with a display name does not mitigate this vulnerability.
If you rate limit the account creation endpoint, you will minimize the ability of an attacker to brute force all usernames of your service, but you cannot prevent an attacker from determining if a specific account exists (apart from assigning login credentials).
Many of the same sites that do this will also have a recovery form that refuses to leak information.
 by “funny” I mean not funny
Maybe the designer should use the site as many of their users use it, and realize the inconvenience it causes people (broken password managers, bad browser experience in general, etc).
Maybe I'm overly paranoid but I choose to manually copy my passwords out of my manager into the login form.
Then again I also use a PW manager that doesn't support cloud storage. (Though you could always throw your DB into Dropbox if you desired)
Holy crap, don't do that. You're eliminating the primary benefit of using a password manager.
Browser integrated password managers can't be phished; they only auto-fill on the correct site, they're not fooled by convincing URLs, and the better ones respect https requirements.
This isn't a matter of convenience. Putting human judgment in the critical path makes things worse, not better, even when it's your own judgment. Don't let paranoia and distrust of automation draw you into a pattern of bad decision making.
And I store my DB in Dropbox, but not the key.
The password manager (implemented correctly) will only fill in the form on the legitimate site. This protects against phishing.
I also have some measures in place to detect. (Ex: hard coded lists of URLs that open in a "financial" container)
I don't claim it's perfect, but it's my way of doing things, I like it, and I don't think it opens me up to an unreasonable amount of risk.
(Also, for lower-value passwords, like netflix, HN, etc I just use my browser's built in password manager.)
With the c+p workflow, you can completely cut out any attack vectors (because the website doesn't interact with your password manager in any way).
I would prefer to trust the pw mgr to send password to only the recorded website, than for me to remember and pay attention no matter how tired or distracted I might be, to what that website is. 'rn' vs 'm' as noted, but also citibank.com vs cittibank.com vs citibankcorp.com, or worse for sites that may not have a .com, how am I supposed to remember it's for TLD .io vs TLD .phisher?
You can only cut out the attack vectors if you act perfectly. That's simply not dependable. All I personally need to reassure myself of this is to look at the number of bugs I write per day.
I didn't investigate in detail but it appears that it is a fake iframe. Even X-Frame-Options et al to prevent 3rd party iframe doesn't solve it because the iframe is fake to begin with!
Very very hard for you to prevent copy/paste to a fake iframe SSO.
I actually can't imagine how it could be safer than having the password manager do it directly.
If the local system is trustworthy, then none of the other programs are sniffing the clipboard looking to harvest passwords. And therefore there is no issue here.
If the local system is untrustworthy and contains malware sniffing the clipboard looking to harvest passwords, then using or not using a password manager is irrelevant . Instead there is a bigger issue needing cleaning up, that of returning the local system to a trustworthy state.
 because an untrustworthy local system running clipboard sniffing malware is also likely running key logging malware, so even if the passwords were only ever memorized they will still get captured whenever they are typed in.
- user copy-and-pastes password
- user forgets to clear clipboard
- user opens a link in a new tab with middle-click
- link was actually a text form
- middle-click pasted the password into the textfield
I noticed this when I had an image url in my clipboard and tried on open a link on imgur.com in a new tab. Instead of opening the link, the image url in my clipboard was uploaded.
So the intention is that I stop some script from siphoning my passwords.
This admittedly opens me up to phishing, but to mitigate I also have containers set up for various facets of my life.
(So it's a big red flag if what's supposedly my bank doesn't open in the "bank" container".)
Edit: I also value storing the database locally versus "in the cloud"
Great Lakes Credit Union is an example of a site that does this.
Cmd + \, Enter, Cmd + \, Enter.
It is a little saddening, perhaps, but to say it’s breaking password managers entirely is a wrong.
I saw it on Expensify yesterday
Doesn't this break a best practice? If you input an email address it tells you whethere there IS or ISN'T a user, and if there IS it asks you for their password.
I thought the best practice was to make it unclear whether an email or username is in the system, which would make this a huge regression
It's useless obfuscation. 99% of systems that tell you "if you entered a valid username, we'll email you a password reset link" also don't allow duplicate accounts by email. Try to register a duplicate on their sign up page and they will tell you "this email address is already in use."
Useless "security" obfuscation and creates a terrible user experience trying to reset passwords.
If the user is confused about their credentials, they'll have to use the "I forgot" system in both cases.
Phrasal verbs, in general, are difficult to speakers of languages that don't have them, especially when the same verb has different meanings depending on the added preposition. Someone with a basic/intermediate level of English may have difficulty telling between "sign in" and "sign up". In my own case, I have a good level of English so I know what they mean, but "sign in" and "sign up" always take 2 or 3 seconds for me to disambiguate, while "login" and "register" (or similar) are instantaneuous.
By the way, this is why an English speaker would say "sign in to a website" but not "check in to a website". Check in is generally a non reoccurring action.
"after the raid, it is known that Brown wrote to Kagi that he would sign into a hotel as I. Smith and Sons. As he began recruiting supporters for an attack"
These are the results I get for web:
- sign in to a hotel appears 0 time in Google.
- sign into a hotel appears 81 times in Google.
- check into a hotel appears 577,000 times in Google.
- check in to a hotel appears 69 times in Google.
I can’t get Google results like those with numbers on mobile, as far as I know. What comes up for me is discussions about what is grammatically proper in this case. https://www.quora.com/Which-is-grammatically-correct-check-i... for instance. All I had to search for was the phrase “check into hotel“, and the results show this is a hot topic of grammatical discussion because that is what came up rather than information about hotels.
‘Check into’ sounds different than ‘sign into’ to me, probably because few say sign vs check for a hotel. I suppose grammatically they’re the same.
I would certainly flag it when editing. I also do not commonly see anyone use the contracted form for this. The reason is that the verb is the phrase “sign in”. The word ‘in’ is not a candidate to be modified by being combined because it is paired with ‘sign’. We would never modify a single-word English verb by adding a suffix like ‘to’, and the same rule applies for phrase verbs. Beyond that, I’m not a grammar expert, so I would imagine the above link could shed more light than I can.
But whatever, ("Sign in" or "Log in") alongside "Register" is clear enough. "Sign in" alongside "Sign up" is confusing. Thanks Al-Khwarizmi for bringing that up... or is it bring in ? ;)
It's better than using true SSO in the sense that "email is decentralized." Yes, that means if their email is compromised the account is compromised, but how many accounts are there are aren't already compromised when using a random password if the email account is insecure? Every story I've heard of an attacker gaining "access to everything" involves attacking the Email account in some way to then password reset everything.
You may also complain that Email is literally not secure so the link could be intercepted unless it was PGP encrypted (somehow). I grant that I think this is perfectly legitimate when the user is facing more advanced attackers (possibly those with passive access to traffic or backend access to emails. NSA or Company IT come to mind) and hence maybe the need for U2F or TOTP.
We get so many "password reset" emails on our old system that I think it'd just be better if they could login with just an email.
Users should use strong and secure methods for their email(s) and websites so err on the side of Magic Links or SSO. Preferably Magic Links because they expose less about the user by default except their email.
I also really like the "go to this website on your computer and enter this code" for logging in to Apple TV, Chromecast, etc so you aren't typing a 30 character password on a TV remote.
If you remembered your password, you could login normally. If not, they would email you the 'forgot password' link, but there was no requirement to set a new password! I only logged in once every few months and could never remember the password, so for me just using it as a magic link system worked well, but frequent users would not be inconvenienced by it since they could use the normal login process.
I hate this with a passion. I'm all comfy in my chair, ready to watch something, and I get the message that I have to get up and go to my computer and do stuff when all I want to do is watch TV. So I watch something else that doesn't require a computer to watch on TV.
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.
Have they ever heard of input type="password"?
This is a weird way to describe keyloggers if that is actually what they are talking about.
The random order I don't understand either unless the "keylogger" is also recording mouse positions.
Otherwise, if this is actually talking about over shoulder lookers it probably has the exact opposite effect because of the increased time require to enter a password.
Unless it's common for keyloggers to monitor the clipboard?
In which case, for the system they've developed to seemingly work as intended, you'll have to either have a memorizable password (likely relatively insecure), or have your password written down at hand.
I'm skeptical that this nonstandard, hostile UX was designed with any sort of valid threat analysis rather some kind of Rube Goldberg-esque security-through-obscurity scheme that "sounded good" during some meeting.
Anything more bespoke than that is probably much rarer.
I would bet that that is exactly what they are worried about. This seems to me to be a really hacky way to solve that problem. If you actually need to address the possibility of keyloggers then some sort of 2FA setup would be simpler, more standard, would address a wider variety of potential security problems, and would create less friction for the user.
1. "Does your account number begin with a *letter*" <- click link
2. Paste Account Number
3. One-time passcode emailed to you
4. Copy OTP from email
5. Paste OTP into site
6. Use onscreen virtual keyboard to enter password (readonly field; no pasting allowed)
And just in case it's not a joke, storing hashes of every subset is laughably easy to crack so that's plaintext-equivalent.
this technique is actually good if implemented correctly -- with secure display where the host OS cannot read the image data. some predecessor to SGX whose name I don't recall had this feature. the idea is to enter a PIN though, not a friggin password.
treasurydirect seems to have only taken away the trivial aspect of it without understanding the underlying reasons and details. you know, like what most companies do with Agile.
"Does your account number begin with a [letter]?",
Where letter is a link. It's like a riddle.