-
We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.
Password Security Justification?
- Thread starter xchangx
- Start date
Lithium381
Lifer
we do this, but it's only on 6th month rotations, can't use the same one you had before or the time before that.....pretty simple
Example:
Text
This is some kid's research paper, but it indicates in theoretical terms how easily and quickly one can brute-force passwords of varying lengths with an average-powered PC.
It is safe to assume that given unlimited time and resources, a dedicated cracker will always achieve his goal. Thus, an IT Security monkey needs to operate under the paradigm of frustrating the average cracker and tracing the expert cracker. This as opposed to making it impossible for the cracker to get through - an unachievable level of perfection.
So the key is multiple layers of defense, and good logging.
For user security this means:
A) Long passwords. Ideally 8+ characters, but 6 can be adequate as long as it is coupled with other measures.
B) NO Dictionary words. I periodically run a dictionary attack on my resources and anybody who fails gets to pick a new password.
C) No dictionary words with numbers stuck on the end. I run a periodic hybrid attack to catch these clowns.
D) Passwords must be a mix of letters, numbers, and special characters. Mixing upper and lower case is good, too. The wider your range of possible characters the longer a brute force attack takes.
E) Passwords cannot be repeated. To help with this, make users wait a few days before they can change their password after they change it. This prevents unscrupulous users from "cycling through" to keep their old password.
F) Passwords cannot be derivatives of previous passwords. No incrementing a number at the end of your password.
G) Passwords must not contain your username or display name.
H) Passwords expire at least every 90 days. Maybe even sooner.
I) After 3-5 failed attempts, the account will lock out either for ~60 minutes or prefereably until an admin can verify the identity of the user and unlock their account. The latter is the "best practice" but it's often not feasible if you have more than 2 people to support.
J) LOG LOG LOG. Log any and all failed login attempts, and if they are network logons as opposed to console logons, make sure you get source IPs! Periodically (weekly at least) check the logs for patterns which indicate something more than a user with a caps lock on.
Hope this helps.
And the ideal solution is some sort of 2-factor authentication a la RSA SecurID. These guys are all but uncrackable.
Text
This is some kid's research paper, but it indicates in theoretical terms how easily and quickly one can brute-force passwords of varying lengths with an average-powered PC.
It is safe to assume that given unlimited time and resources, a dedicated cracker will always achieve his goal. Thus, an IT Security monkey needs to operate under the paradigm of frustrating the average cracker and tracing the expert cracker. This as opposed to making it impossible for the cracker to get through - an unachievable level of perfection.
So the key is multiple layers of defense, and good logging.
For user security this means:
A) Long passwords. Ideally 8+ characters, but 6 can be adequate as long as it is coupled with other measures.
B) NO Dictionary words. I periodically run a dictionary attack on my resources and anybody who fails gets to pick a new password.
C) No dictionary words with numbers stuck on the end. I run a periodic hybrid attack to catch these clowns.
D) Passwords must be a mix of letters, numbers, and special characters. Mixing upper and lower case is good, too. The wider your range of possible characters the longer a brute force attack takes.
E) Passwords cannot be repeated. To help with this, make users wait a few days before they can change their password after they change it. This prevents unscrupulous users from "cycling through" to keep their old password.
F) Passwords cannot be derivatives of previous passwords. No incrementing a number at the end of your password.
G) Passwords must not contain your username or display name.
H) Passwords expire at least every 90 days. Maybe even sooner.
I) After 3-5 failed attempts, the account will lock out either for ~60 minutes or prefereably until an admin can verify the identity of the user and unlock their account. The latter is the "best practice" but it's often not feasible if you have more than 2 people to support.
J) LOG LOG LOG. Log any and all failed login attempts, and if they are network logons as opposed to console logons, make sure you get source IPs! Periodically (weekly at least) check the logs for patterns which indicate something more than a user with a caps lock on.
Hope this helps.
And the ideal solution is some sort of 2-factor authentication a la RSA SecurID. These guys are all but uncrackable.
Yeah, I think that's a pretty reasonable policy personally, but pitching it to the suits always does present a challenge. First off, I would soften them up with some recent security threats you've discovered, even if it's as simple as an employee or two visiting a hacking site at work. Once, I put a manager's work assigned e-mail address into Dogpile and searched on it and gave him a personal profile on his life. Then, with his permission, I used it as an example to everyone in the management staff to plant the seed that they're not annonymous and that anyone out there could easily have gathered the info that I did in a short time. Then, with their newfound fear of security, I used that to push the issue further up the chain. It was quite effective actually. Also, although it's not really a problem anymore, in another session I trained them on the fallacies of the WinNT hashing algorithm on Lanman hashes and how a password is basically saved as 7 characters and if one character in the password is found by brute force, the rest will soon fall. Taught them on dictionary attacks, etc. and then they really, really took interest and started using a password generator app that I placed on the network for them. At this point, virtually everyone uses a pretty secure password and they try to outdo eachother on memorizing their complex generated passwords (mine is 14 characters with blah, blah, blah characters in it). I've found in my personal experience that you have to get everyone on board and give them a reason. Everyone always asks, WIIFM (what's in it for me?) and if you show them what's out there on the 'net about them just based on their e-mail, etc, they'll come on board real quick for the rest of it although they're distantly related security issues (personal vs. professional). Hope that helps and sorry for the lengthy reply.
Those are all well and good, but minimum length passwords and "no dictionary words" DECREASES the average amount of time needed to crack the system.
As long as the cracker knows the rules of the system (which any good one undoubtedly should), he'll know to leave out 1-5 and 9-x letter words, along with adding a dictionary of his own. With the number of possible passwords reduced several thousand fold, he achieves his goal much quicker.
That's a MINIMUM of 8 characters. The theoretical max limitation in NT is 14 characters. It would be hard for a cracker to guess at the minimum length of a particular system, although if he knows he's hitting an NT system, he knows not to bother with anything over 14.
Also, the time it takes to get through passwords of less than 6 characters by brute-force is quite negligible. A cracker will blow right through that space. Specifying a minimum length isn't a trick to foil the cracker, it is a trick to prevent users from creating easily cracked passwords.
However, I don't see how eliminating dictionary words decreases the time needed to attack a password. If a password is immune to dictionary and hybrid attacks, the only remaining attack is a much more time-consuming brute force attack. In fact, dictionary/hybrid attacks take a negligible amount of time compared to a brute force attack on the alphanumeric + symbol set of characters. Most "smart" crackers will pitch the dictionary/hybrid attack first and get it out of the way. It's a throwaway attack.
Which goes back to the paradigm of frustration and not elimination. Since the most determined threats are going to keep going well past a dictionary attack, there is nothing we can do to stop them by restricting the length or scope. We have to use other methods for them.
However, we can at least turn away the more casual crackers who are looking for easy targets and just using dictionary attacks.
Mach,
Correct me if I'm wrong, but a top of the line system that's used for cracking just dictionary words on a hash will take mere minutes, right? So if a dictionary attack will take just minutes, can't we just say that allowing dictionary words is pointless? If all it's going to do is buy minutes, but allow the cracker to get the password anyway, then why the hell permit dictionary words in the first place? You're basically trying to say that because it's easy to crack a dictionary word, but it takes time to do so, that it's okay. Yes, we may save the cracker time by publishing a policy preventing dictionary words, but I'll give him/her a few minutes saved time to make it more difficult in the long run to try and crack good, multi-faceted passwords of more than 8 characters.
Correct me if I'm wrong, but a top of the line system that's used for cracking just dictionary words on a hash will take mere minutes, right? So if a dictionary attack will take just minutes, can't we just say that allowing dictionary words is pointless? If all it's going to do is buy minutes, but allow the cracker to get the password anyway, then why the hell permit dictionary words in the first place? You're basically trying to say that because it's easy to crack a dictionary word, but it takes time to do so, that it's okay. Yes, we may save the cracker time by publishing a policy preventing dictionary words, but I'll give him/her a few minutes saved time to make it more difficult in the long run to try and crack good, multi-faceted passwords of more than 8 characters.
It really makes more sense to think in the reverse sense. Since it takes minutes to blow through a dictionary attack, why would a cracker NOT use it? Thus, if you allow passwords susceptible to dictionary/hybrid attacks, you are essentially throwing easy targets to even the most casual crackers. Eliminating these weak passwords, OTOH, will remove the threat from casual crackers, and at least provide a stumbling block for more determined crackers.
It only saves the cracker time if the cracker can find out the intricacies of the target's security policy, but it is often very hard to figure all this out, especially the minimum lengths and character set.
The ultimate goal is to provide as many stumbling blocks as possible, and quickly detecting/carefully logging anyone determined enough to get through all the stumbling blocks.
That's kinda what I was getting at to Jzero, just had a hard time putting it into words. Oh well. I know what you mean and I think you know what I mean and we both agree and have similar policies. If Mach wants to throw up easy targets by permitting dictionary words, I guess it's his perogative.
Just remember not to be so harsh with it that your users start writing them down because then you defeat yourself if you get too draconian.
About the securid, there's a neat scenario about bypassing those in mitnick's the art of deception, which I strongly recommend to anyone who deals with security and policies.
MisterPresident
Golden Member
I hope that's a joke or something.
I can't comment on crack times. I'm neither black hat, white hat, or grey hat - I don't f*cking have a hat. ;D
But this is what I'm saying:
On the sysadmin side, you need to let ANYTHING be a password. Dictionary words, names, usernames, whatever. However, you need to also DRILL into the employees head some rules. Rules that aren't defined in the system. Rules such as not using dictionary words, not using reversed words, etc etc.
You're probably asking "why? Why set up the system so loosely, if you impose rules on the meatspace side?"
Because you want the cracker to have no other option than to assume that your system IS using dictionary words, and isn't using a set password length.
No password is uncrackable. Given the computer power and time, any password can be cracked.
The only hope is to simultaneously
A. Make the cracker's span of possible passwords be as large as possible
B. Make the users select passwords that are not easily decipherable
An interesting writeup on the subject was done here.
We're saying the same things, then. The difference is that I do this for a living, so I differentiate between what is written and what is electronically enforced more readily. There is nothing in NT that allows you to ban dictionary words without using third party software. That rule is strictly policy based. The rules I presented are based on the SecAdmin knowing his system well enough to know which rules are going to written policy and which rules are going to be enforced by the system automatically. Not all of those rules are electronically enforced, but all of them are part of the policy.
Glad we're on the same page, though 🙂
bunker
Lifer
Active Directory can't do this?
I'm only asking because I know that's what we use and our pwd restrictions are a minimum of 8 characters, at least two numeric, changed every 90 days, no repeats....ever.
I hate the no repeats one, but c'est la vie.
(btw, I'm a dba, I try to stay far away from you sysadmin bastards 😉 😛)
It won't do dictionary or hybrid attacks on the fly, nor will it compare the password to the username and display name.
It will let you specify:
Min length
Max length
Expiry time
Complex/Simple (mix of letters, numbers)
Days between changes
Number of passwords to "remember"
How many bad attempts cause a lockout
Lockout duration
I think that's everything.
this thread is probably the first thread ive seen in OT that looks like it belongs in HT
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 25K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 24K
-
-
