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.

colan
  • 409
  • 4
  • 6
  • Is the threat different for entering an existing passphrase? I forgot where I've seen this but there was a field which would present a random number of asterisks when pasting your password. You'd have to assess your threat model. What's stopping someone from listening to the number of keyboard strokes you use to access your password manager and then just crack that password. If rate/attempt limiting is properly implemented then it would barely matter that your password was just 3 or 4 chars. – MonkeyZeus Sep 01 '21 at 17:45
  • 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 01 '21 at 21:40
  • I added another paragraph above to provide more context about what I'm actually doing. – colan Sep 02 '21 at 02:36
  • 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 02 '21 at 06: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](http://hallofshame.gp.co.at/lotus.htm#LOTUS12) wrong with it :-D – Aaron F Sep 02 '21 at 08:20
  • @AaronF Well the system I am thinking of still logged you in no problem so the random asterisk length is not a problem/bug, just an extra security measure. – MonkeyZeus Sep 02 '21 at 12:13
  • @MonkeyZeus Lotus Notes logged you in, it just made it more annoying if you made a typo halfway through by accidentally hitting two keys, and couldn't tell how many letters you'd typed, so you'd have to delete everything and start again. They also didn't think about the obvious "What's stopping someone from listening to the number of keyboard strokes" that you mentioned :-) – Aaron F Sep 02 '21 at 16:09
  • If the length is 0 or 1, I might start my career as a hacker. – Thomas Weller Sep 02 '21 at 16:13
  • 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 02 '21 at 16:15
  • @MonkeyZeus: that's why you press a random key and backspace whj^Hile entering your password. Should be a habit of Sysadmins IMHO. BTW: later versions of Notes even removed Xs while typing, not only adding them. – Thomas Weller Sep 02 '21 at 16:16
  • @ThomasWeller If you can actually distinguish the number of chars that a sysadmin typed for a password without using a recording device then you should be awarded 10 minutes of uninterrupted attempts to crack their password, hah – MonkeyZeus Sep 02 '21 at 16:22
  • 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 02 '21 at 18:33
  • I'd prefer a number over a long string of asterisks. – Oskar Skog Sep 03 '21 at 09:04

6 Answers6

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

Gh0stFish
  • 4,664
  • 14
  • 15
  • 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](https://security.stackexchange.com/a/93628/42391)). 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 '21 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 '21 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 '21 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). – Toby Speight Sep 01 '21 at 13:41
  • _"pruning to the length,"_ which is the entire basis of this question. Naïvely, the search space is reduced by 1/charset-size. I agree that there are speed-ups if you make diceware assumptions (especially if you're _really sure_ you know how many delims there are between words). That might be some fun Python. – Michael Sep 01 '21 at 17:35
  • @Michael: If you're dealing with a diceware passphrase, then it is necessarily a *long* passphrase. Counting that many dots/asterisks via shoulder-surfing is hard, so you're probably better off just recording the sound of the keyboard instead. At which point masking the UI makes no difference. – Kevin Sep 01 '21 at 23:47
  • 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. – Stian Yttervik Sep 02 '21 at 07:40
  • @Kevin Oh for sure, yes. I just think it'd be interesting to see what effect it has to cut out all the permutations of words that exceed the length or are less than `totalwordlength + 2 * wordcount`. – Michael Sep 02 '21 at 13:19
  • As far as I'm aware, Donald Trump's twitter password was cracked without any bruteforcing software, just by a human user trying guesses manually. If knowing the length could have saved that user a lot of guesses, then it would certainly have helped. – Stef Sep 02 '21 at 17:43
  • What about the situation where the account is known to have a 46 character password? Brute forcing all passwords from 1 to 45 characters would take a *long* time, but brute forcing just 45 character passwords would be comparatively quick, though still a huge time right? Then again, by that point, is the difference mostly academic? – James Geddes Sep 03 '21 at 12:30
  • @JamesGeddes Brute-forcing a 46 character password is ~100 times slower than brute-forcing all 1-45 character passwords. But both of them are completely impossible (as, impossible under our existing understanding of the laws of thermodynamics) - so it's completely academic. – Gh0stFish Sep 03 '21 at 13:03
  • @Gh0stFish Very interesting, thank you! Yay for exponentials. – James Geddes Sep 03 '21 at 14:12
  • Or you could show informative message only if zero-length password is entered (which is invalid condition); which would not reveal any extra information to potential attackers, while still clearing up the problem. – Matija Nalis Sep 03 '21 at 14:25
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.

Cort Ammon
  • 9,206
  • 3
  • 25
  • 26
  • 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 02 '21 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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 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](https://security.stackexchange.com/a/254793/42391). – Adam Katz Aug 31 '21 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 02 '21 at 23:30
  • @DanBryant Yes [there](https://www.schneier.com/blog/archives/2016/10/eavesdropping_o_6.html) [is](https://www.schneier.com/blog/archives/2005/09/snooping_on_tex.html) research on inferring keystrokes from acoustics. – nobody Sep 03 '21 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.

Austin Hemmelgarn
  • 1,625
  • 7
  • 9
  • 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 01 '21 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.

Adam Katz
  • 9,718
  • 2
  • 22
  • 44
  • 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 '21 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 '21 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 '21 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)

RobKohr
  • 101