30

When users are entering a new passphrase somewhere, it's helpful to provide feedback on the number of characters received by the system.

In a user experience (UX) test I just ran, my user created a passphrase in her password manager, and then attempted to paste it into the new passphrase prompt in the terminal. But because there's no feedback provided on the current system (i.e. the cursor doesn't show entered dots), it wasn't obvious that the paste didn't work.

So from a UX perspective, it would be better to show some dots so users would be aware of what characters actually came in.

Could this feedback decrease security in any significant way? Obviously, it would give shoulder surfers the length that could be used to narrow an attack scope, but I'm hoping the impact is minimal for the better UX.

To provide some context, this if for the terminal command-line interface (CLI), specifically interactive input prompts in Ansible. It provides no feedback right now, but I was thinking about opening a feature request to do so, and was wondering about the security implications.

13
  • 13
    NIST 800-63B states that password entry fields SHOULD allow passwords to be pasted in, as encouraging the use of password managers which can assure a lack of password reuse and use higher-entropy passwords.
    – Randall
    Sep 1 at 21:40
  • 2
    @colan "new passphrase field" -- so this is not a field but a terminal prompt? You've misrepresented the whole context? Story aside, your question is "what is the security reason why terminals don't show feedback on password prompts?" Are you also aware that this behavior in terminals is pretty universal and has been for decades?
    – schroeder
    Sep 2 at 6:37
  • 2
    @MonkeyZeus "I forgot where I've seen this but there was a field which would present a random number of asterisks when pasting your password." - Lotus Notes! That was one of the many things wrong with it :-D
    – Aaron F
    Sep 2 at 8:20
  • 2
    @AaronF They did random asterisks as you typed? Well that's annoying, copy+paste is one thing but doing it live is a bit short-sighted. The main deterrent of someone listening would be whether they can distinguish shift key presses; extra points if you can detect the shift key being held for multiple chars. All of this probably doesn't matter anyways since my impression of Lotus Notes users is that the password was sticky-noted to the monitor anyways.
    – MonkeyZeus
    Sep 2 at 16:15
  • 1
    @schroeder I updated my question to clarify; sorry about using the work "field". Yes, I'm aware terminal apps have been doing that forever, but that doesn't mean it should never change. If we can improve UX without negatively impacting security too much, why not?
    – colan
    Sep 2 at 18:33
39

Knowing how long a password is doesn't really make much difference to how easy it is to guess or crack it.

If the password is something easily guessable or in a dictionary, then the length is irrelevant.

If the password is random and you're trying to brute-force (having somehow obtained the hash), then knowing the length makes very little difference, because of how fast the cracking time rises with length.

For instance, let's say that you know the password is 8 characters long, but you don't know what kind of characters it's made up of. Brute-forcing an eight character password (assuming 95 possible options for each character) at 60 billion hashes/second (from MD5 on a decent GPU) would take ~31 hours.

If you don't know the length of the password, then you might try brute-forcing shorter passwords first. But brute-forcing all of the passwords from one character to seven characters only takes ~20 minutes, because each additional characters makes the attack take 95x longer.

So by hiding the length of the password, you're only gaining a very marginal (i.e, around 1%) benefit, and only in one very specific circumstance (and attacker trying a brute-force attack against the hashes).

13
  • 6
    Calculating that 31h crack time is the worst-case scenario (the password is broken at the very end). We typically assume half of the space is enough, making your estimate 15.4h per cracking GPU (see my cracking math). A 0-7char random password would take 9.7 minutes per GPU, so while saving 10min is indeed negligible, but you'd save 15.4h breaking a 9char pw, 60d for a 10char pw, 15.8y for an 11char pw, ...
    – Adam Katz
    Aug 31 at 19:28
  • 25
    The absolute time savings certainly increase as the password gets longer, but given that the overall cracking time increases proportionality I don't think it really helps much. Sure, saving 15.8 years sounds like a much bigger time save. But if it means that the password takes 1501 years to crack rather than 1517 years then that still seems pretty negligible.
    – Gh0stFish
    Aug 31 at 19:44
  • 3
    If you assume pure random characters, you're right. If you assume that the attack starts with the dictionary and the password is a two word passphrase with a random delimiter (100k*95*100k, bit entropy=40), the crack time is 8 seconds, and that's before the massive savings you'd get pruning to the length, which is more complicated math than I'm interested in estimating.
    – Adam Katz
    Aug 31 at 19:53
  • 3
    If you know the lengths of several users' passwords, that gives an indication of which ones you're most likely to be able to crack (users with minimum length passwords disproportionally choose low-entropy ones too). Sep 1 at 13:41
  • 3
    But isn't it correct that knowing it is a 7 character password allows for the attacker to adjust their strategy? If the attacker knows the password is 16 characters, they'll do some dictionary attacks and go to next. Attacker can optimize the strategy for x users knowing the lengths of their pws, given what hashrate is available to them. Sep 2 at 7:40
13

UIs with this behavior do exist. I've seen several that do not offer any visual feedback. I've also seen a few that do random feedback.

Is it a security issue? Well, consider how long passwords tend to be. I think 8-15 characters is a reasonable expectation from users (there are users who will break the bank with longer passwords, but we'll skip them for now). There's 8 possible password lengths in that range, which means you are "leaking" 3 bits of information.

Given that I don't believe there's any password strength algorithm which can give results accurate to within 3 bits, I think there's good justification as to why virtually all password inputs leak this information. The user experience is sufficiently valuable to outweigh the security benefits (remember, usability and security are always in a balance. You can't focus just on one or the other).

Indeed, I am finding more and more systems that offer to reveal your password, if you click a button. So, if anything, practical systems are starting to go even further away from "obscure the length of the password."

The only attack I can think of that is really meaningfully affected by this would be if I happened to shoulder surf the password length across an entire company, and used that to prioritize shorter passwords to try to crack first. But even then, its hard to argue which was the problem: the displayed password length, or the fact that it was a weak password in the first place.

1
  • And, of course, its worth noting that cryptographic keys tend to leak the fact that they are 64-bits, 128-bits, 256-bits, etc. in the algorithm description. That information simply doesn't factor into the security proofs, so it doesn't matter that it's revealed.
    – Cort Ammon
    Sep 2 at 14:28
9

The threat scenario is extremely limited. One would have to be physically present and be able to count the "dots" to get a length. This is more difficult than being able to read the text since there is no pattern for a brain to efficiently parse. Then they would still have to brute force the password.

Even if the attacker gains knowledge of an approximate range of length, providing feedback in this manner does not decrease the risks to the credentials in any significant way.

3
  • 3
    Somebody could alternatively be virtually present. Thanks to COVID-19, I think most folks in tech have seen somebody enter a password while screen-sharing. At least the keyboard isn't visible for virtual shoulder surfing! IMHO, most of the security risk is removed when the site has a sensible password length requirement as noted in my answer.
    – Adam Katz
    Aug 31 at 16:12
  • The virtual presence scenario is interesting because the attacker not only has a recording of the number of dots, but also the rate at which the dots appeared and potentially audio information of the keyboard presses associated with the dots as they appeared. Not sure if there's been research on it, but there's potentially exploitable information there.
    – Dan Bryant
    Sep 2 at 23:30
  • @DanBryant Yes there is research on inferring keystrokes from acoustics.
    – nobody
    Sep 3 at 10:45
6

In general, no, this provides only extremely limited security gains in exchange for a significant UX downside.

Not showing typed characters has two advantages for security:

  • It hides the password length.
  • It limits the viability of very specialized and highly targeted timing attacks on the password entry itself.

The first ‘benefit’ is of limited value given how normal brute-force attacks work. The norm for bruteforcing a password is to work up from some lower character limit to an arbitrary max number of characters. Because knowing the length only effectively saves you from time spent checking shorter passwords, but the number of possible passwords scales exponentially proportionate to the length of the password, the time savings possible is negligible (it’s maybe a few percent on average).

The second ‘benefit’ protects against avery specific type of theoretical attack. Effectively, if you have data on delay between each character being entered in the password, you can combine that with a very large amount of typing data from the target user to optimize the search order for a bruteforce attack. In practice, this would be exceedingly unreliable, collecting the reference dataset would be absurdly difficult without already having a keylogger on the victim’s device (at which point, you’re better off just using that to scrape the password), and the victim just using a password manager completely sidesteps the issue. Despite all of this, I’e actually heard people talk about this type of attack seriously as an argument for hiding entered characters of a password, hence my mentioning it at all here.

In contrast, you end up with zero feedback to the user that typing anything is working, which is a huge UX limitation for many users, especially when they’ve been trained to expect obscured characters to show up.


On a side note, you should avoid the behavior that some websites and a lot of 10-foot UI designs have of showing the last character typed for a second or until a new character is typed. That still protects against casual attackers, but anybody actually looking to actively steal a password just needs a camera with a decent resolution and a fast frame rate to read a user’s password, and the usability benefits are negligible compared to just having a button to let the user unhide the text.

1
  • How about limiting updates of the number of characters typed to about 5x-10x/second? That would be fast enough to avoid adversely affecting the user experience, but would mean that someone with video of a screen wouldn't be able to glean nearly as much information about the rate at which someone was typing a password.
    – supercat
    Sep 1 at 22:27
2

I do not consider seeing the number of characters in a password to be particularly telling. Any attacker can see the password given sufficient access to your browser (say with a rogue add-on) or OS (with a software keylogger) or hardware (with a physical keylogger).

I consider the risk of somebody seeing your password length to be a minor one. There are two ways it could happen. The more trivial of these is shoulder surfing, which has more to do with an attacker watching your fingers on the keyboard and is, like a keylogger, irrelevant to somebody using a password manager.

The other risk is when you enter a password while sharing your screen.

This can be controlled by HTML/CSS on a web server by using a narrower text box, say one that is eight (masked) characters wide. Then only passwords shorter than eight characters will be notable to an observer, and the site's password policy should reject such insecure codes.

My shorter-password-input proposal does limit UX a bit; you can't verify that you're successfully adding text after the eighth character. I don't consider this a major drawback, especially since the best practice is to use a password manager (so you're pressing a magic login button or else pasting it all at once).

If there's concern about double-pasting a password, you could have some sort of animation, like shaking the box or briefly changing its background color each time the value changes.

3
  • 1
    I think you are assuming a browser-based password manager that enters the password for the user. I think that assumption needs to be explicit.
    – schroeder
    Aug 31 at 16:47
  • @schroeder – The server's CSS dictates the width of the pw field. I certainly prefer browser addons that can fill in credentials, especially since I have a clipboard history tool that would save passwords I paste, but my original text pretty clearly called out the button-vs-pasting difference. Is it common for people to hit Ctrl+V twice? You could toggle between white and gray backgrounds on keystrokes to minimize that, but I see that as a corner case.
    – Adam Katz
    Aug 31 at 19:58
  • As someone with a tremor in my hands, ctrl-v twice happens quite a lot, actually. If I can't see that I've pasted twice, I can't undo
    – schroeder
    Aug 31 at 20:13
0

I would consider the display of dots to be a non-threat when entering a password. It gives very little information even on video. And considering users will also be typing in passwords, the sound of typing lets people know how many characters there are.

As far as showing how secure a password is, a bar that fills up to full and changes to green when full is good.

A calculation of quality could be the number of characters in each character type represented and added up, and then put to the power of the number of characters typed.

For example, just using lowercase letters with 5 of them would be:
26^5 = 11,881,376
with lowercase
(26+26)^5 = 380,204,032
with numbers too
(26+26+10)^5 = 916,132,832
or with 9 characters
(26+26+10)^9 = 13,537,086,546,263,552

You could use this to give whatever level of strength on a bar, and maybe set a threshold where it would be good enough to be passable.

I find this to be so much better than some arbitrary character type requirements that are usually given. They can still be given as a suggestion though.

Also you can load a dictionary of the top common 1000 or 10000 passwords (I'd load it async after other page assets are loaded). If the password is in there or very similar to one of them, let the user know their password is one of the most common on the internet and shouldn't be used.

Usually those password lists are lowercase. You can put them in a json array that can be loaded, and then do a

const userPassLookup = userPass.toLowerCase();

if(passwordList.find(pass=> userPassLookup.includes(pass) || pass.includes(userPassLookup))){
  // tell the user to try harder
}

(Note this is just a sketch and could use improvement)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.