Is it acceptable practice to only increment a number when changing a password?

Question

Note: I'm not asking about this password scheme is the best or not (of course it isn't); I'm asking about its theoretical or practical secureness relative to the optimal password scheme based on the algorithms commonly used in authentication and encryption. As I already say in my question, mathematically this scheme (as I've defined it here) is as secure as what people are told to do (but rarely do; though irrelevant here), but I don't know whether there are weird aspects of authentication or encryption that invalidate the mathematical analysis based on entropy alone.

Well so I had this interesting thought. Since password-protected systems often require users to change their password frequently, many people just increment a counter appended to some prefix, such as:

awefjio;1

awefjio;2

...

I wonder whether using such a family of passwords is as secure as choosing a completely random new password each time, as long as the prefix is uniformly randomly chosen and as long as each random new password plus about 10 bits. I ignored the extra bits from the counter since that might be guessable within a small error margin given the frequency that users are required to change their password. Mathematically this password scheme is good enough because the extra 10 bits lets the attacker try 1024 times as long to crack the password as compared to the completely random one, assuming one does not change a password more than 1024 times. (Here I'm assuming the attacker somehow has a hash of the password, including any salt needed.)

Now I know one obvious disadvantage to this, which is that an attacker who somehow gets hold of the current password will know all previous passwords, nevertheless this seems completely irrelevant in most practical situations, where once logged in the user has full access to his/her account and never needs the old passwords.

Hence my question; is there any concrete reason why users should not use this scheme for changing passwords? I'm guessing that if the answer is positive, it will depend on the authentication or encryption algorithms involved themselves, in which case I'm fine with restricting the question to the most commonly used algorithms.

To be clear, I'm only asking about the situation where:

1. Users have no choice but to change their passwords at some fixed frequency, and do not have the option to use a password manager (such as on a workplace computer). They therefore have to decide on some scheme. This question is about whether one particular scheme is better than another.

2. Choose a fixed constant n. I have in mind n ≥ 64 at minimum, if that matters.

   a. The first scheme is to choose a new independent random string with n-bit entropy every time one needs to change the password.

   b. The second scheme is to choose a fixed random string with (n+10)-bit entropy and append a counter that is incremented every time one needs to change the password.

The question is whether (b) is at least as secure as (a) for common types of password-protected systems.

Answer 1

If an attacker has found out your password, he can access the system up until you change the password. Changing passwords often prevents attackers that already have your password to have undetected access indefinitely.

Now, if your password is secret-may16 and the attacker is locked out when you change your password, he is certainly going to try secret-june16 as the password. So changing the password in a predictable way is not secure.

Answer 2

You should not use this scheme, because once this password is known to an attacker, he can derive the "later" passwords.

This could be the case in these situations:

• The password is shared between you and some other trused persons, and some day you decide to not trust (one of) them anymore. In this case, they could easily guess the next passwords.
• An attacker gets hold of the password. Once he cracks it (which might take some time) he can then guess the derivations of the password.

By using such "numbered passwords", you destroy the (little) security benefit of changing passwords regularly.

Related Question: How does changing your password every 90 days increase security?

Answer 3

Changing only some portion of the password is [citation needed] very common, and a very bad practice.

Entropy is a measure of how unknown something is. for the first time you choose random-fixed-beginning or a whole new password, both with the same amount of entropy, both alternatives will be equivalent. Ok.

For the time you need to change your password, if you are completely sure that no previous password will be discovered, you're also good. Because something that is not known will keep the same amount of entropy.

But... and there's always a but... what if some previous password is recovered? Or two?

That can happen with sites/systems that store previous passwords in plaintext. Can also happen with sites/systems that store previous passwords as hashes.

Because plaintext, well, will easily show that your previous password was IamGod_april16. And someone will try using IamGod_may16... Just changing a part, in some predictable way, will easily expose your new password.

Even if it was stored as a hash: it will be harder when properly done, but what if someone brakes the hash and discovers what your password was? He then will be able to try IamGod_december18, and if you didn't change your scheme in the future... bang! Got hit because of a leak that happened 2 years before.

See that is doesn't matter if the "IamGod_" part is random, is human-readable, or whatever: what kicks you is that some part of if can leak some information: the month, the number, the letter in the end... even if your scheme was "IamGodh", someone could try "IamGodi", "IamGodj", and so on.

So, the first part of the answer to your specific question on whether the (b) scheme is less, equal or more secure than (a): it isn't more secure. Because if just use a changing number, changing month, changing letter... in the end, it's very easy to try new combinations, be it offline or in some online system.

And there is the second part: even if you devise a very good scheme, and the changing part is in the middle of the password... what if someone recovers 2 or more old passwords? And finds out that they were "3VQ2NMkK", "3VQ3NMkK" and "3VQ4NMkK" ? Well, can you see some pattern?

So, (a) and (b) can even be equally secure if your scheme doesn't get detected. But it's a strong assumption that one can devise a good scheme, so, in general, it's very safe to assume that (b) will be less secure, for any kind of system.

Of course, that assumes that the system gets broken somehow: that the database is leaked because someone invades a site, or because some internal folk copies the database, or someone looses the backup tape, or the maiden runs a man-in-the-middle attack inside the company, or because some update in the site leaked the password, or because the heartbleed attack revealed some passwords, or because the company let one old computer to be available in the network, or...

Given that those situations (and many more) are beyond your control, the advice is to choose the safe side: just don't assume that old passwords won't be leaked.

Answer 4

Keeping a specific scheme is never a good idea even if enterprise environments that require frequent password updates/changes. For example if, like in your example, someone kept the same basic characters and only changed the password by a single integer, someone whom learns an old password could use the scheme to predict the changes. Take for example, the tool called "crunch." Using the example you provided, all possible permutations of the scheme could be generated and used in a dictionary attack.

#!/bin/bash

crunch 9 9 0123456789 -t awefjio@@

Crunch will now generate the following amount of data: 1000 bytes
0 MB
0 GB
0 TB
0 PB
Crunch will now generate the following number of lines: 100 
awefjio00
awefjio01
awefjio02
awefjio03
awefjio04
awefjio05
awefjio06
awefjio07
awefjio08
awefjio09
awefjio10
.........

And so on and so forth. Keeping a predictable password pattern makes hacking into credential-protected website login forums very easy. It is best practice to make a unique and completely new password each and everytime. Another thing that is a threat is the information gathering stage of hacking. The more a hacker learns about a target's habits, likes, dislikes, hobbies, family names, birth dates, special life event dates, etc, the more they will have to go on with dictionary/wordlist creation for cracking a login.

So to answer your question, no, it is not, ever, in any circumstance, a good practice to use simple integer increments with password changes,

Answer 5

Yes it is.

Requiring users to regularly change passwords is a counter-productive bit of security-theatre (see CESG article) as it forces users to write down their passwords. If an attacker has managed to obtain a password, then they may have several weeks to install back-doors or slurp gigabytes of data off the system anyway before the password is next changed.

Using a simple numbering scheme allows you to pick a password that you can remember without writing it down, then you can game the system to allow you to keep using your memorable password indefinitely.

If your existing password has n bits of entropy, then it will continue to have as much entropy as any other n bit entropy password. Constantly switching passwords doesn't change that. Adding a single digit on the end adds about 2.3 bits (ln(10) bits). But even if your numbering scheme is so easily guessable that it adds no entropy, you still have the n bits you started with.

If the hashing algorithm used is any good, then a password a will hash to what appears to be a random string. Another password b will give what appears to be a completely different string (except in the extraordinarily rare case of a hash collision). There should be no possible way, by looking at the two hashes, to determine whether the two passwords are completely different, or vary by only one character (perhaps a digit on the end). If it is possible to tell if only one character has changed, then your hashing algorithm is broken, and you need a better one.

The same argument goes for any encryption system used to transfer passwords from a client to a host. If two similar passwords give similar encrypted messages, then the encryption is already useless.

Answer 6

In your case, the security of the sequencing scheme is decreased primarily due to non-cryptologic factors. Consider shoulder surfing. If you type the same password, day after day, year after year, your coworkers or other observers could notice the patterns. You could type the same password in different locations that have different levels of physical security, such as a coffeehouse, where an ordinary camera could pick up the password.

Consider the case where the attacker doesn't use the knowledge at the same time as they learn it. I may be a co-worker who accidentally observed your password last year, but this year we're bitter rivals for the same account. Knowing one of your old passwords was qwerty1007 and another was qwerty1011 means I will be successful with some pretty simple guesses.

By employing a pattern, you increase the risk of loss over a longer period of time.

[ Your proposal superficially resembles a common scheme used by two-factor authentication systems. A user has to enter a remembered password, plus they have to enter a code displayed on their hardware device.

But the reason it's secure is not that the security is markedly improved by the size of the code from the token; it's that the system will limit the number of incorrect password+code guesses to a finite number, then lock out the user ID. ]

Answer 7

I would elaborate somewhat on the explanation Sjoerd gives and approach it from a somewhat different angle.

First one should ask what security goal is being achieved by the scheduled (as opposed to reactive) change of passwords? Why is your security division or best practice document forcing you to change a password every couple of months?

There is a couple reasons:

1. to complicate brute force attacks

   When someone gains access to the hash of your password chances are it will take them a fair amount of time before they manage to break it. If the amount of time to perform a brute force attack is longer than the validity period of the password they can't actually profit from gaining the password since you have change it already

2. To bound the amount of time that a compromised password may be useful

   People do not always find out that their password was compromised. A regular password change makes sure that the password doesn't allow the attacker to get in forever. (Of course in some cases when they are in once they are in always due to malware, apt's what have you but this is not always the case.) This also takes care of situations where the attacker only finds out about the compromise late due to some circumstances.

3. To slightly curb password reuse

   People will often reuse their passwords in multiple systems (work and private). Most private systems (gmail, that sports center registration web page etc.) don't force regular password changes so chances are that even if the user starts out with the same password everywhere password changes will make him differentiate them.

4. To bound pass the hash attacks

   If an attacker only gains access to the hash of your password he can often use that hash to authenticate against the systems if he/she is sophisticated enough. Changing the underlying password will change the hash and thus again stop the attacker.

Now we can ask how do the two schemes you propose stack up against the goals we've outlined. In any case where the attacker gains access to the plain text of your password (certainly 1,2) the first scheme (incrementing) is much weaker then the second. Any non-brain-dead attacker will try incrementation. In the third situation it's a bit more tricky to judge since it depends on whether the password on outside service contains the counter at all and in general what the real impact of the regulation is. For the fourth goal the incrementation is pretty much on par with the second scheme assuming the hash function used behaves closely enough as a random oracle.

All together just incrementing the counter on a password is certainly much weaker than choosing new arbitrary passwords, but by just how much depends on the types of attacks you expect.

Answer 8

You should roll an entire new password.

If there isn't a breach, I don't see the value in constantly rotating passwords. However--when you do rotate passwords, this is the key:

You want to regenerate the password using a system with the same assumedly secure constraint you made the original password under. I.e. incrementing a number is NOT acceptable because you're only making a one byte change since you probably had a generator give you P3588swrOd4.

So if your password rules are 3 actual random words "BadgerYtterbiumLancet" picking a new non-random word, it makes your password much more guessable, "BadgerFoxSquirrel".

The other big issue with just incrementing passwords is it creates a situation--say your company does this for 10 years...people change passwords every month. You're creating hashes of the passwords that are dangerously similar to one another. (this is why you use anything 'random', 'picking' passwords--well people tend to use Password, a common phrase, etc.) You want as much uniqueness to every password compared to each other--you want to treat new passwords for the same thing as new passwords. I.e. Password1, Password2, 3,4,5,etc. this ends up in a really bad place. Even worse if you are compromised and fix the problem, if your data is valuable to the cracker, you can bet they'll try near variations of what they found to work before.

Also, it should be noted that it's insecure for people outside your organisation (i.e. fired/old employees) to know the method for password generation. Again this is why I point back to the 'random'--nobody should know how to predict your password generation beyond something vague "they picked 4 random words in the dictionary" or "they used a strong random password generator".

Answer 9

If your password database is leaked, a good password can take some time to crack. By which time, quite likely, you have been forced to change your password. That concept is a large part of why these "security theater" forced password resets exist.

HOWEVER, gaining access to your account is typically handled using an automated script. If the password attempted fails, then the script still has a few more attempts until lockout. If, on May 12 2016, a password like "fredJune15" was rejected, and the script has been informed that the data was acquired in July 2015, then the script might well try fredApril15, fredApril12, fredApril16 before lockout: you have given the script clues for things to try.

If the script knows the password-reset-period to your system, or can guess it, then it can guess with a simple incrementing number, about how many times the number will have been incremented. So "fred12", after seven forced password reset periods, will almost certainly be "fred19". Password reset periods are almost always a month, so guessing them will almost always work.

Worth noting as well: if you use the same password across multiple systems, but with different numbers because one gets incremented at a different rate, or because you created your accounts at a different time, then if one system is compromised, both systems are.

So in short: no, generate a new random password each time. Use a password manager. If you can use two-factor authentication, do so.

Answer 10

When I'm cracking passwords I will get your new password within the same second if all you do is increment. This is because I'm trying appended and prepended passwords before anything else and only after qwerty related schemes and the basic list of discovered passwords since it's been my experience that's what we humans are apt to do.

Answer 11

Probably not the most secure answer, but I recently heard advice about what to use for passwords that change regularly: What is your goal or something else you are looking forward to doing in the next X months? Use that to make a password. So, if you are going on a trip to Disney World before your password is going to expire you could do something like Looking4wrd2SpaceMtn!

In X months, when that password expires, consider something else, maybe a goal you are working on: Wrk-out-35mincard!o

Your password can't be deduced from previous passwords (if you are smart about it), they have decent length, and they help you remember a goal you are working on or an event you are looking forward to.

If the trick is trying to remember the password and it changes frequently, I think this isn't a terrible option.

Answer 12

You might be somewhat safe if your suffix looks like a year of birth.

If I use myname1977 then there is less, but probably not zero, chance that someone knowing that password will guess that I changed it to myname1978.

But why take the risk? (do as I say, not as I do; I increment, but only at work, because that's the only place that asks me to change my password and, as far as I am concerned, anyone in the company is free to see everything on my work PC. Your mileage definitely will vary).

Personally, I find Edward Lear to be a great source of inspiration for passwords :-)

And the simplest, most memorable, "tick all the boxes" of minimum 8 characters, one number, one upper case & one special character is surely cat plus one big dog AKA cat+1Dog