If you're nutso for network security, the NSA's 60 Minute Network Security Guide PDF (yes, that NSA) should get your network up to brick wall status in - apparently - 60 minutes.
The guide, which checks in at just under 50 pages, is serious about airtight network security, urging you, for example, to enforce a password history of at least 24 different 12+ character passwords, swapping out passwords at least once every 90 days. The free PDF covers Windows and Unix security setups.
It would probably be more useful to go in the front door...
formatting link
Security Configuration Guides - Overview - NSA initiatives in enhancing software security cover both proprietary and open source software, and we have successfully used both proprietary and open source models in our research activities.
Security Configuration Guides > All Current Security Guides > Applications > Database Servers > Operating Systems > Routers > Supporting Documents > Switches > VoIP and IP Telephony > Vulnerability Technical Reports > Web Servers and Browsers > Wireless > Archived Security Guides
From a first look it seems to contain good advice, although there are some mistakes (e.g. passwords in /etc/shadow are hashed, not encrypted), and it seems to be a bit outdated on the Unix part (several Unices don't use Sendmail anymore, but other MTAs like e.g. Postfix). However, it is only a starting point (and doesn't claim to be anything different).
Good plan. You know what your average use does with a 12+ character password? Guess... Oh that's right, sticky note on the monitor.
It will take your average use 4-6 weeks to learn the password (assuming they only enter it a couple times a day), which means by the time they learn it, they're half way to being forced to get a new one.
Worse, if someone does compromise a password, they'll have an average of
Sebastian, Do you think it is advisable for an administrator to know USER passwords? How many administrators do you know that would be happy to assign ALL their users a new password at a regular interval? What would you suggest the renewal period to be?
Give them passwords? If I knew, or even had the ability to easily determine my users' passwords, that would be an even bigger security breech then sticky notes.
Depends on your setup. On the other hand, you can make such suggestions of good and easy passwords to the users while also holding them responsible for the actions submitted under their accounts (thus they'll care to actually choose good passwords).
Depends on the setup. For some hundred users grepping through a subtitle file of a favorite movie to extract some short quotes might be worth the effort.
I didn't criticise that. 30 to 90 days are a good choice.
It rarely, if ever, 'depends on the setup' Have you heard of BOFH?
Having user accountability should be foremost. It does not follow that they will automatically select strong passwords - most users wouldn't understand what is required for a strong password, hence we have system password policies.
Without getting into the how's and where's you would get said subtitle file from, I would not be happy to set 100 or so passwords up manually, nor would I be happy to reset them on a regular basis. Our network consists of a lot more than 100 users, thus making the task considerably more time consuming.
The biggest problem I have with the above method is you will now have a large file with all your user passwords in it. It would now be trivial to generate hashes of the passwords for cracking purposes. AKA a dictionary attack, albeit a dictionary with long passphrases rather than words.
I didn't suggest you criticised that. I was wondering what the overhead would be to change the passwords on 5000+ user accounts every 30-90 days. Not my idea of fun and I'm sure our network administrators will have me taken out and shot if I suggested such a thing! :-)
Having system password policies means that the system at a certain point actively checks the unhashed password, thus is almost equivalent to the administrator knowing the password.
There are lots of freeware password crackers out there that can easily determine a users password. All you need is access to the password hashes and even a child could do it. The more complex and long a password is, the better. Having a 16-20 character password is much harder to crack with "off-the-shelf" tools than the 8 character passwords that many password policies use.
Sure -- I could probably even decrypt the SSL transaction when they entered their password -- But should an issue come up, the fact that I probably couldn't do it without finger prints means I have plausible deniability.
If I provided the passwords in the first place, I don't have that.
Something you are, something you have, something you know.
Finger print or hand scanner (can they be defeated? Sure. But it's a barrier to entry)
RSA SecurID, smartcard, even a magnetic swipe would do the trick.
Passphrase (length, but no other complexity requirements -- It's goal is only to be secure long enough for a stolen RSA SecurID to be noticed, and must be easily memorized)
Meaning that you'll have to increase the complexity of your infra- structure, which *may* open additional attack vectors.
How do you handle a compromised token? Fingerprints are pretty easy to spoof. Also with biometrics there's always a tradeoff between FRR and FAR.
A token could be copied without the holder noticing (except for SecurID maybe, but that one comes at a price).
You probably won't notice that a token got compromised, because it was not stolen but copied. Thus the password needs to be as good as the other tokens, which leaves you with the original problem.
Don't get me wrong, n-factor authentication is a good thing as it raises the bar, but it's not a silver bullet and it's not for everyone. You need to be aware of the downsides (price, increased complexity) and possible issues (FRR/FAR tradeoff, tokens being copied, ...). Also don't forget that the document we're talking about is a "first steps" guide and nothing more.
Besides, n-factor authentication does *not* address the problem of the mean timeframe that an account can be exploited (which was my question). It just helps to reduce the risk of a compromisation.
True. But security in general comes at a market-regulated price.
RSA -- for which I've been a been a consultant for 20 years -- would never claim that the secret seed in its AES-based SecurIDs can not be retrieved or copied with some amount of work, access, special knowledge, and time. No one but a fool will claim that any security model is impervious to all attacks.
OTOH, RSA does claim that its Model 800 SecurID hardware token -- the standard SecurID -- and its various derived form-factors are designed to be highly resistant to DPA and the other types of timing attacks that offer potentially dangerous avenues of attack against the whole class of hand-held hardware authentication tokens. To the best of my knowledge, only RSA's SecurID offers this level of defense against side-channel attacks.
The SecurID -- and probably whole class of hand-held authentication tokens -- are designed not to be tamper-proof, per se, but to be "tamper-evident."
The idea is that the user, at least, should be able to recognized that someone has broken the seal on the token, even if it has been put back together again so that it apparently still works. Users get to know their tokens pretty intimately, and are supposed to be trained to report that sort of thing. Network and security managers are bred to react with appropriate paranoia to this type of report. ;-)
In addition, I think all 2FA devices rely upon their remote authentication server to automatically suspend a user's account if it receives some number of good token-code, bad PIN/password, combinations. With RSA's SecurID, I think the default is three.
A sufficiently strong smart cards implementation can too. Assuming both the card and server have certificates and all communication is encrypted, and both the card and server keep track of how many times they've communicated, and the timestamp of the previous communication, the attack timeframe is reduced to when the card is stolen, to the next time it is used.
It would require the attacker to also have access to the passphrase, and the ability to defeat the "something that you are" problem during that brief window.
Another way to prevent copying is to require the "something that you have" phase requires user authentication (okay, this is back to "something that you know") before proceeding, which raises the bar to cloning considerably.
All that being said, within my own company, it's just a password for me.
Sigh. It's the Model 700 SecurID, not the USB-based Model 800, that is RSA's standard AES-based hand-held authentication token. Beg pardon for any confusion.
Ansgar -59cobalt- Wiechers also raised another question:
Various 2FA vendors probably have different responses to the threat of very sophisticated attackers who could potentially (temporarily) steal, illicitly clone, then return a user's authentication token with little or no evidence of the theft or copying.
Self-evidently, this threat is a/the critical factor in defining the whole spectrum of 2FA devices -- in particular the range of technical security that can be provided by the various software-based token emulation devices, but also the relative security provided by various devices among the nominally more robust hardware-based authentication tokens.
It should be clear to all that where technical security is less than robust, as with software-based "tokens" and some hardware devices, it falls to the users and their managers to provide the level of physical and virtual security necessary to ensure the safety, security, and integrity of the AAA system.
I don't know how other vendors address the question 59cobal raises, when they are forced to do so, but RSA's standard SecurID system
*does* address the question of mean time to discovery for even an illicitly cloned SecurID. RSA really focused on the threat of side-channel attacks on its SecurIDs early. It responded with multiple levels of defense when it designed a new SecurID for the 21st Century. A true SecurID clone fails or gets spotted very quickly. This is not, unfortunately, something RSA has given me permission to discuss publicly, so I can only say that the question is one which you can discuss under NDA with your RSA SSE or, if you are a potential customer, with your RSA salesperson.
It's an interesting question if you are comparing products to determine the best-of-breed system for environments which demand a high level of security assurance.
At one company where I consulted, a given token could ONLY be used on your assigned desktop or laptop, no where else.
There were a number of fireable offenses to help ensure the human component, including leaving the token unattended in the building (you were required to carry it on your person at all times -- Pocket, purse, or hand basically -- If you wanted to get someone fired, pretty much all you needed to do was get their SecurID and turn it in to security)
The same for storing the laptop and RSA token in proximity of each other (unless the RSA token was on your person) whether at work or not (okay, this would be tougher to enforce in practice)
Having both your laptop and RSA SecurID lost/stolen was a fireable offense as well (with some discretion -- Leave them in your car together, it gets stolen, you're gone... House burns down, you're not expected to rescue your RSA SecurID before running out the door or anything stupid like that)
All in all it wasn't a big deal, not many people had laptops anyway, so it mostly just meant something else on your keychain, keep your keys in your pocket, and life was good.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.