Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Password rules: Change them every 25 years SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Password rules: Change them every 25 years
The lion's share of these posts all assume access to the hash or lack of failed login response. How does the discussion change if we assume:
- x failed login attempts triggers an alarm or other response
- the attacker does not have access to the hash
- the system is only addressable from the "internal" network
- the password in question is for a non-user account (eg. an app logging in to a database)

I've been reading NIST SP800-63 "Electronic Authentication Guideline" and NIST SP800-118 "Guide to Enterprise Password Management (Draft)" and they both seem relatively silent on non-user passwords. (much like this discussion thread)

Has anyone seen any vetted recommendations on the rotation passwords tied to non-user accounts? Specifically, non-user interfaces between application or infrastructure components?

3 Posts
Many here are against sticky notes, but I PREFER them:
Having a weak password is much worse than a good and very strong password which must be written on a sticky note since it _is_ impossible to remember. Most have them in their mind after about one or two month of daily usage. However I suggest them to put _that_ note under the keyboard or in the desk drawer so it is not visible from outside just by looking through the window.

For users which must have a strong password (10 characters, upper+lower+number, admin password longer) I do create them, and we write it up, and we keep a list which user has which password. Not all users (and companies) need such passwords, I only use that sadistic password rule for any account that has access from the outside without VPN, or with VPN from an "unknown" non-controlled machine.

To get the list, or one user password, someone has to break in the house, and once someone is IN the house it does not matter since he simply can take all the hardware he needs which makes any password useless. And in case of the list (with the admin password) some one has to take a safe with a few hundred kilos, fixation to the ground and wall, with them + still be faster than the police.
1 Posts
Some years ago, I try to change the 30/60/90 password aging policy at my place (and failed). I didn't found much information on Internet to convince.
I agree more work need to be done on improving user knowledge about how to make good passwords, avoiding password sharing and enforcing good accounts management. If it is applied, you can have password expiration in years with no problem.

Few links i found

Few Official policies
(down) 180d 120d
(down) 1/year 6-12 months
(down) 1/6 months 1/year

10 Posts
To "Interface Admin's" question about non-user accounts, I can point to a number of previous assignments in which a service account's password was exposed. Because the password had not been changed in years, it was deemed 'too dangerous' to change the password without spending several months investigating what services and applications used the password.
View password changes as a "mini disaster recovery exercise", to demonstrate that you have working processes in place for changing passwords when you need to do so in a hurry.
I go into a little more detail at
1 Posts
As others have said time and time again, the actual password rules are often inadequate. Most requirements don't improve security or, worse still, downgrade it. The fact is that easily remembered passwords such as "under-the-volcano", or even more simply "ping-pong-pang" or "dd-cc-bb-aa" are strong. The problem with these, of course, is that examples are needed to explain the principle and naive users will simply copy one of these.
3 Posts
Now, I'm not a bigshot in my company, but from my understanding of security, I'd do the following:
Assert two extremes:
1) Organized, forceful attacker, who will guess passwords "fast", which is asserted to be ~1 week - this is with weak password, and a forcebrute attack. I don't know whether it is realistic. I'm just throwing it out there.
2) Disorganized, social-engineering-ish attack which hit the one-in-a-million user or never really amount to anything. General time to get a single password is probably about 25 years as is asserted in this story.

Using these two, we assert that either may come our way (more or less depending on size and popularity of cooperation - I assume that MS gets a lot of bruteforce attacks for instance).

To properly resolve (1) we'd need to change passwords every week. Doing this would prove a huge burden for every single user, which even the most paranoid security person will agree is excessive (I'd think).
To properly resolve (2) we just have to use fairly strong password policy (8 alphanumeric characters, at least one special symbol (!#_: etc.), small and large letters, and at least one digit.).
To resolve them both in a fair way would be to take some kind of average between the two based on how often (1) occurs and how good we (the IT-department) are at intercepting said attempts.
The better we are and the less it occurs the closer we get to 25 years reset time, and the more it happens and the worse we are, the closer we get to once per week.
Assuming proper security precautions for #2 is in place, I'd wager the cracking time for a password (even if you've got the hash) escalates into about a year or more before one can crack a single password. Optimally (or at least from what my brain can cope with right now), that'd mean an on-average password reset time of about a year.

I believe, thus, that once per year would be fair - perhaps a friendly message once half a year has passed to the user. This will encourage users to figure out smart, difficult and unique passwords each time and on the same time, make sure they don't have to change it with such a frequency that they end up writing them down and thus dramatically lowering security.

1 Posts

Sign Up for Free or Log In to start participating in the conversation!