Export thread

Was just wondering if @Steve thinks password padding is still a valid way to increase password length without majorly sacrificing security. Many websites and services warn against or do not allow three or more repeating characters. I didn’t know if some of the password/hash cracking utilities have been modernized in a way that allows them to take advantage of repeating characters. I use a password manager for websites, but use padding for WPA2/3 passphrases (to make them easier to type 63 characters) and master passwords on occasion. Is this still advisable?

If "the essence" of your password is short (1-6 characters) then padding with a few repeated characters is a bad idea. This is likely the reason why many sites think they're being helpful by blocking repeats. They're assuming you're working around the minimum password requirement. For example if the rules say the password must be 10+ characters and have lower and upper and a numeric, and you do this, Ab1!!!!!!! then you do not have a very secure password. If on the other hand you do JHG9d8H!7*&Ghjhg!!!!!!!!!!x then your password is perfectly fine even with repeats.

PHolder said:

If "the essence" of your password is short (1-6 characters) then padding with a few repeated characters is a bad idea. This is likely the reason why many sites think they're being helpful by blocking repeats. They're assuming you're working around the minimum password requirement. For example if the rules say the password must be 10+ characters and have lower and upper and a numeric, and you do this, Ab1!!!!!!! then you do not have a very secure password. If on the other hand you do JHG9d8H!7*&Ghjhg!!!!!!!!!!x then your password is perfectly fine even with repeats.

Click to expand...

But wasn’t Steve’s whole point about password padding that since it is a hash, an attacker would not know how much padding, or that there is padding. Therefore, in theory, “horsestaple1batteryvvvvvvvvvvvvvvvv” should be the same difficulty as “hors1vvvvvvvvvvvvvvvvvvvvvvvvvvv” (assuming they were the same number of characters, I was too lazy to count lol). Wasn’t that his original logic?

The logic was to make a shorter password longer. The logic was not to make an unsafe password safer. It's a subtle difference to be sure. It has to do with how attackable a password is by brute strength alone, and not by another means such as using rainbow tables or lists of known passwords.

So start with a secure (i.e. long random) password, and you can lengthen it against brute force attacks by padding. This will NOT work if the attacker has the base password in a data list and is aware of how to lengthen it with padding.

PHolder said:

The logic was to make a shorter password longer. The logic was not to make an unsafe password safer. It's a subtle difference to be sure. It has to do with how attackable a password is by brute strength alone, and not by another means such as using rainbow tables or lists of known passwords.

So start with a secure (i.e. long random) password, and you can lengthen it against brute force attacks by padding. This will NOT work if the attacker has the base password in a data list and is aware of how to lengthen it with padding.

Click to expand...

Excellent point, I recognize the distinction between lengthening a good password vs. padding a bad one In attempt to make it good. However, my main point of contention is the last part of your statement. I was a long time ago when Steve discussed it, so my memory may not be clear, but I believe one of his main points is that without the attacker knowing if you use padding, how long that padding might be, what the padding might contain, etc., a 20 character password that started out as, say, 6 random characters, should in theory be sufficiently difficult to crack to a blind attacker, since they have to approach it like any other password hash. I understand it will never be as strong as random characters, but might it be sufficient for a master password + 2fa scenario?

To add to my previous question, my main question would be, what is the tipping point where a padded password goes from weak to strong? Surely there is one, where the time to crack it would go from this lifetime to the next, quantum computation aside.

This doesn't exactly answer your question. But, FWIW, I use 32 or 64 character random strings either from Lastpass or @Steve 's site for everything (if the equipment / site will take that). I store them in Lastpass and copy and paste them as needed. If I have to have something that must be typed, I use a minimum of 4 words separated by numbers and symbols. In the case of a DVD player, etc. where you have to type with arrows on a remote, making the password all caps or all lower case can help. Also, printing the password on paper as a reference and breaking it into 4 character sections can help. This technique can help even with random strings. If you need something like a guest wifi password, a medium length pass phrase that they can type on their phone can be helpful. Some systems allow you to let them scan a QR code to enter the password. The guest network should be separate from your main network and should generally only be able to access the internet.

May your bits be stable and your interfaces be fast. Ron

The strength of a password needs to have a context. Think of the key for a deadbolt in a door. You can make the key more robust, you can make the deadbolt more robust, and you can make the framing more robust, but in the end, the attacker might break a window and go through that.

For our context, we'll assume the attacker has the password database and the usernames and emails are in plaintext. If the passwords are also in plaintext, you're hosed. You might be hosed EVERYWHERE you used that password and the attacker can try it anyway, because why not.

If the password is securely hashed, and your password is common, then the hash will be easier to find with rainbow tables and other efforts to simply look up encrypted passwords. If your password is short, then this approach might also work. These days an attacker might well have all possible 10 or less character passwords easily found by a simple lookup. (Because, unlike in the past, memory and storage have become cheap as compared to the past.)

Now if we've eliminated the easiest to find passwords, now we're kind of left in a weird territory. Are you being personally targeted? If yes, then the attacker may continue to put more and more effort into your specific compromise. If not, then it's likely there will come a time where the amount of effort (read cost) will exceed the value of any returns, and the attacker will move on to something new. At this point you might be okay for now, and for who knows how long, but as time moves on, they may come back with a new tool or new approach and try again.

So in the case of your specific question... you want to know where is the trade-off point for password length. I would suggest that is currently somewhere around 12 to 16 characters, depending on the attacker and the value of the asset (is it bank passwords, or is it a streaming service password.)

Personally, as Ron mentioned, I use random, LastPass generated passwords that are 30 or more characters long, unless the site won't accept one that long. (Looking at you Microsoft/Outlook.) But for my LastPass password, I have to use something I can remember, so my password is around 20 base characters but I use a padding strategy to make it longer and hopefully stronger.

Mostly I am concerned for WIFI passwords. It is hard to get people to type in 30+ characters on mobile/iot devices. Even though it is a separate iot network. I am trying to make security easier for people (family) who don’t realize the importance. At some point, if it is too difficult, they will circumvent the process somehow. These are people who refuse to use password managers (in some cases) and carry around little books with their passwords. If I told them to copy and paste the password to another device, they would probably post it to Facebook to copy it back from to facilitate the transfer easier.

@Sushi This might help with transferring credentials from device to device, or not depending on the circumstances. This example works on my Android 9 tablet. I don't know about other Android versions or about IOS.

* Connect to the wifi network of interest.
* Tap settings.
* Tap connections.
* Tap Wi-Fi (do not tap the switch to turn it off, tap the Wi-Fi label)
* It should show the name of the connected network under "Current network".
* Tap the network name.
* It should show a QR code that you can scan on another device to log into the network. (I've never tried this, so I don't know how to finish the process.)
* Also on this same screen if you scroll down are settings for auto reconnect, metering, and DHCP.

Hope this helps.

May your bits be stable and your interfaces be fast. Ron

Padding fails faster with brute force, simply because at some point, early on in the testing, there will be your padding as a good part of the guesses, and thus it will fail before the theoretical half way time, often, with only a small initial weak password, with a lot of padding, very early on. Simply because of the cycling through each of the possible permutations will result in a lot of all one character being there.

I'm wondering how padding can actually fail faster? In order for that to be the case, the attacker using brute force has to know the length of the password somehow. I think if brute force is being used, just about any password more than maybe 16 characters (if not less) will be skipped.

SeanBZA said:

Padding fails faster with brute force, simply because at some point, early on in the testing, there will be your padding as a good part of the guesses, and thus it will fail before the theoretical half way time, often, with only a small initial weak password, with a lot of padding, very early on. Simply because of the cycling through each of the possible permutations will result in a lot of all one character being there.

Click to expand...

If I am reading this correctly, padding would actually make a blind bruteforce take even longer than the standard password since:
- the attacker's only information is whether or not the attempt was successful
- the attacker must search up to the padded password's length (which is strictly larger than the unpadded password length)
- Once at the length (unknown to the attacker), the attacker must also search up through the password
The only case I can think of presently that the padded password would be equivalent(ish) to the unpadded is if the unpadded password does not fulfill a minimum length requirement, and thus a pad is required to satisfy this requirement. In this case since the original password was invalid, the security of the two passwords cannot be compared. This analysis completely disreguards rainbow tables, hash cracking, and other password cracking methods and merely focuses on brute force.

Maybe I am misreading your comment? It almost reads as if the attacker can determine if a character was correct (like in the movies where they gradually reveal the password), but that may not have been what you intended to convey and is not how password cracking works.
By fail faster do you mean that the bruteforce method will take longer, because the way you say it implies that padding is the point of failure?

I don't understand @SeanBZA's point either. The only way I can see padding failing faster if if you have a padding aware password cracker. That might work if the padding is always the last thing in the password, but it doesn't have to be. Let alone the possibility of it being something like: I__________Like__________Chocolate__________Chip__________Cookies!

PHolder said:

I don't understand @SeanBZA's point either. The only way I can see padding failing faster if if you have a padding aware password cracker. That might work if the padding is always the last thing in the password, but it doesn't have to be. Let alone the possibility of it being something like: I__________Like__________Chocolate__________Chip__________Cookies!

Click to expand...

Even “padding aware“ shouldn’t help with good padding. I often use a sequence of characters for padding. I’m just failing to understand how this is weak? There are so many ways to pad with sequences, character, lengths, and like @ctc said, the attacker only is pass/fail.

example pad:

chocOlate$42+-+-+-+-+-+-+-+-+-+-+-+-+-+-+%

Pipe that to your hashcat and crack it

Sushi said:

chocOlate$42+-+-+-+-+-+-+-+-+-+-+-+-+-+-+%

Click to expand...

That's harder to type than a good 4+ word pass phrase.


Ron

rfrazier said:

4+ word pass phrase

Click to expand...

Having spent all together too much time with dictionaries for my recent Wordle recreations, I can assure you writing a tool to try combinations of words wouldn't be hard at all, and probably already exists. You need some of the difficult to type characters in there to make it more difficult to brute force by "style". That's why I liked my example about cookies

PHolder said:

example about cookies

Click to expand...

I liked your example, although that one would be starting to get a bit hard to type on a touch screen device. I will admit to not having read every single word of this thread and to not being a password expert. You mentioned context in one of your posts and I think that's very important. Trying to crack the hashes of a stolen database is a bit different from trying to crack a wifi password which I think @Sushi was talking about. Assuming remote admin is off and not buggy, wifi at least requires physical proximity to attack. It might also be subject to login rate limits on the router, etc.

I guess my point was that it seems to me that a pass phrase of 4 words with some minimal padding between is probably adequate. I don't think you need lots of padding. As I understand it, the math would go something like this:

word1 alphanumeric alphanumeric
... word 2 alphanumeric alphanumeric
... word 3 alphanumeric alphanumeric
... word 4 alphanumeric alphanumeric

So, baseball32starshine32molecule32mongoose32 as an example.

If there are 2048 words in the dictionary, that's 11 bits of entropy for each word. That assumes the words are not mixed case. Each alphanumeric could be A-Z, a-z, 0-9. That's 62 alternatives. If you just add 2 symbols, you're up to 64, which is 6 bits of entropy. So, the grand total would be 92 bits if I'm doing the math right. That's maybe not great but still pretty good, and still pretty typeable, at least once in a while. I don't THINK it's possible to capture WPA data from the air and brute force it that way offsite, but I could be wrong.

Here's a good review of some of the issues involved. One issue is that humans are terrible at being random. They may use correlated words or patterns which reduce the effectiveness.


If I had to share wifi passwords with people, which I don't, I definitely like the idea of using QR codes to scan if possible. If not, I'd probably gravitate toward something like this method. Hope some of this makes sense.

May your bits be stable and your interfaces be fast. Ron

Short password with padding, to meet a minimum password length, is going to go through all the characters in sequence, so padding, front, middle or end will be closer to the middle point of the total number of tries, simply because the repeated characters tend to fall earlier in the tries. Only after exhausting minimum length will you go to doing it with another character on the end, and repeat till you will either have a correct response, or, if the need is to pass a hash, get a hash collision, which results in the same result.

SeanBZA said:

the repeated characters tend to fall earlier in the tries.

Click to expand...

I don't believe this to be the case. The only logical approach is to try every possible character in the alphabet (96 or so if you exclude Unicode) as you slide the password length.

So if you assume the password minimum (so no point testing smaller) is 8 chars.
Then your first set of tests is 96^8. When all of them exhaust, then you will start over with 96^9. Then 96^10, 96^11, 96^12 and so on. Every time you add an additional character to the length, you are forced to do an additional 96 times more work.


If you want to cover every possible password of each possible length you need to sum all these up... longer passwords just make it harder and harder and harder. Math is hard!

I'm getting better​

It could be argued that Steve seemed to dismiss the idea of Padding with the episode titled The Death of Clever and, in my mind, that episode serves as a bookend to that period as the following year Steve would have the SQRL revelation and would no longer focus on improving human password generation. 2011's Off The Grid would be his final project related to human-generated passwords.

Even the phrase "death of clever" suggests that Steve was moving on to think more about the larger authentication problem and less about human password generation, which could not be solved with clever tricks. The eventual result of this shift was, of course, SQRL, which would consume nearly a decade of of his life.

Leo even brought up padding specifically during the Clever episode and though Steve would not state outright that "padding is dead", he repeatedly steered the conversation back towards "clever" no longer being valuable and, to my knowledge (and search abilities), the phrase "password padding" has never again been mentioned on the show in this context. At the time "Clever" aired, Steve was obviously thinking differently than he was during the "Haystacks" days. However...

Padding was never a solution to entropy, which Steve consistently acknowledged. I felt that password padding was neither as novel as Steve initially believed nor as powerless as he seemed to later suggest. It is what it is: a tool. If used properly, tools can be quite useful. Many people were already "padding" in practice (i.e. for WiFi passwords) before it became a Security Now topic, but Steve named, fleshed out, and popularized the concept and deserves credit for doing so.

Mathematical effectiveness​

I will absolutely pad WiFi passwords if it helps users to type it into their device. I tend to use words for WiFi passcodes as I think people are comfortable with typing them, even in password fields where auto-type is disabled. Random words can even be thought of as "pre-padded entropy" as they are not worth the entropy of an equal-length string of random characters, but are worth more than a single character. We can use repeated characters for padding where convenient, but I do not count repeated characters in my strength calculations.

If I take the passphrase:

1steed2shining3sea4food

I choose to count the effective characters as:

1st2shsefo

which is 10 characters from the decmial+lowercase set with a dictionary size of 36. I consider this to be 51 bits of entropy and offer a haystack size of 3.7x10^15 guesses. This is not strong enough and the words aren't random, but it should suffice for this example.

I count each word as equivalent to 2 characters out of convenience as there was some agreement long ago in the newsgroups that each random dictionary word offered entropy similar to 2 random ASCII characters. 2 ASCII characters totals 13 bits and Diceware has a dictionary size of 7776 or ~13 bits per word; other dictionaries are larger, but there are diminishing returns to dictionary size beyond this magnitude. For example, a dictionary size of 100,000 only gets us 16.6 bits per word and most people are not using obscure words anyway.

I do not count the characters as full ASCII in this example because the password contains only decimal+lowercase and I err on the side of weakest-case when estimating strength. This is also why I only count the first 2 decimals as they are in a simple counting pattern of 1-2-3-4; I should not get full credit for random decimals when I've instead use ordered decimals as padding.

We could pad the password further, perhaps like:

@start----1steed2shining3sea4food----end@

I would consider the effective character string for calculations to be something like:

@s-1st2shsefo-e

which is 15 characters from the decimal+lowercase+ascii_symbol set with a dictionary size of 69. I consider this to be 91 bits of entropy and offer a haystack size of 3.8x10^27 guesses. I don't count the repeated "-"'s or the last "@" as they are part of simple patterns, but calculated complexity still went up substantially. I'm also counting the words as only 1 character each rather than 2 because they are simple words and part of a simple pattern. Again, I err on the side of weaker when calculating.

By my methodology, the padded password is substantially stronger than bare, but this is simply because the password is longer, not because the padding itself is strong. So long as we include substantial entropy in the password, preferably a random-generated string, the padding still serves the same purpose that it always did; adding length while potentially making the password convenient to type.

Lengthening random strings​

I should also show an example with better entropy. If we generate a truly random 14-character ASCII string, such as:

zX7V9_0xdH4lG7

and then add padding, such as:

123456------zX7V9_0xdH4lG7-------890

(6 dashes after the number 6 and 7 dashes after the number 7)

then we have produced a substantially longer password while using only a 14-character sequence of random, hard-to-type gibberish. I don't like counting repeated characters, but simple forms of padding are still perfectly valid so long as you understand that some minimum amount of entropy is required as a baseline. No "clever" attack can reduce this example password to less than 14 random characters of strength and in reality it will be stronger than that. How strong isn't worth debating as we can know for certain that it's "equal to or greater than" 92 bits.

Repeated symbols can be harder to type than non-repeated symbols as you can lose count of how many dashes or periods you've entered, especially as most password fields are protected by asterisks as you type. I tend to avoid them for this reason, favoring words instead.

Passphrases​

I make an effort to create WiFi passwords that are easy for human beings to type even without seeing them and find that words are easier to type than long strings of repeated characters. I use words as implicit, or integrated, padding. I try to use words that people can understand when spoken and I currently tend to use numbers between the words as that creates a sort of ordered list. My method is not better or worse than any other, so long as total entropy is sufficient for the application. I only bother with padding when making passwords that must be typed by hand.

I do recommend using truly random words where practical. There are websites that will generate random words, such as this one and this one. You can even get more obscure words, albeit one at a time, from here and generate structured sentences (i.e. noun-verb-adjective-noun) here. I don't use full sentence generators as the sentences tend to make sense and thus are not very random; I want nonsense and nonsense can even help with memorization, if necessary. Everyone should learn at least a little about mnemonics, in my opinion.

As some will point out that it isn't "secure" to obtain randomness from the web, rest assured that you can generate a sequence of words by choosing every 3rd one in the list after every page refresh or something like that; you can even combine words from multiple generators. Be creative. If you have a paper dictionary, feel free to use it, but I don't bother. I do tend to avoid complex, unknown words if friends and family will need to type them, however.

And so...​

Feel free to pad your passwords; just make sure that they contain some minimum amount of entropy overall. Simple padding sequences like "____" or "===" should not be counted towards your entropy goal even though attackers will have to guess those sequences; be harsh when estimating strength. It is so incredibly easy to make passcodes that cannot be guessed with a trillion dollars worth of electricity that there's no reason to be generous when estimating strength; assume the worst and prepare accordingly.

It's easy to get caught up in the minutia here and I hope to encourage readers to step back a bit and simplify things. We don't need to debate "where" the padding should go or be the hardest to guess. It doesn't matter. Simply:

1. Use padding only where humans will need to memorize and type a passcode
2. Ensure that a minimal level of randomness exists

92 bits or 14 random ASCII characters worth is a good starting point, though I prefer even more for WiFi passwords. If you ensure a minimum level of randomness, padding can only make that password stronger, no matter how you use it. It's not possible for padding to be stronger or weaker at the beginning, end, or in any particular location; padding is just low-entropy junk that makes a passcode longer.

So, there is no best way to use padding. You add enough randomness to resist best-case guessing attacks and integrate padding as desired. To estimate strength, either ignore the padding altogether or assume that it adds only a few characters of brute force strength. Padding can either be explicit as with repeated characters or sequences or implicit as with dictionary words. Either way, it is a useful tool and is certainly not dead. It feels happy and thinks it will go for a walk .