Password Padding

[Sushi]

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?

 

[PHolder]

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.

 

[Sushi]

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.

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?

 

[PHolder]

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.

 

[Sushi]

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.

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?

 

[Sushi]

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.

 

[rfrazier]

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

 

[PHolder]

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.

 

[Sushi]

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.

 

[rfrazier]

@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

 

[SeanBZA]

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.

 

[miquelfire]

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.

 

[ctc]

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.

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?

 

[PHolder]

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!

 

[Sushi]

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!

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

 

[rfrazier]

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

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

Correct Horse Battery Staple

Ron

 

[PHolder]

4+ word pass phrase

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

 

[rfrazier]

example about cookies

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.

Correct Horse Battery Staple Review | Fractional CISO

Our Correct Horse Battery Staple review discusses the importance of creating strong passwords. Read more for tips on how to keep your information safe online.

fractionalciso.com

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

 

[SeanBZA]

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.

 

[PHolder]

the repeated characters tend to fall earlier in the tries.

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.

96^8   =           7,213,895,789,838,336
96^9   =         692,533,995,824,480,256
96^10  =      66,483,263,599,150,104,576
96^11  =   6,382,393,305,518,410,039,296
96^12  = 612,709,757,329,767,363,772,416

To test every possible password of length 8 to 12:
         619,159,333,646,776,538,234,880

As you can see, the lower rounds don't count for much
because of the scale of the later rounds, so you can
almost ignore them when doing rough estimates.

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!