Discussion on:

Don't be fooled by the argument against unique passwords

Useful risk information comes with numbers, Chad.

What's the probability of this actually happening to a particular individual?

Just as interesting is the use of unique passwords for important sites, like the bank, and a "throw away" password for sites that just want to know who you are but don't have anything particularly private? What's the risk scenario and how probable is it?

It'd be interesting to see a complete data breakdown.

On the other hand; putting on a seatbelt does not increase complexity enough to justify not doing so when in the car. Using a password manager and strong passwords does to increase complexity enough not to do so. Heck, use a site specific five character random string for your username rather than a common username across all sites.

Granted, there are probably a lot of people doing the low security general password and strong passwords on more sensitive sites. At least they are conscious of what sites are more sensitive and are better off than the one password fits all folks.

My password to here, and most other sites, is dead simple. Want to buy stuff on my steam account, much longer and harder password, my bank account, crazy long.

Agreed: several, or many passwords of varying strength. If someone cracks my pwd for this site they will only be able to post here.
If only I could convince my IT dep't that a mandatory pwd change is counter-productive. Tommorow's new pwd is no better/worse than today's, and many colleagues have to write down/post new pwds because of frequent changes.

And its forcibly changed on them every 2 weeks. They don't even get to choose the password.

Basically everyone there keeps the password open in notepad on their computer all the time so they can copy and paste it in, and they have it written down. This is beyond pointless already.

The really need to consider a password manager. At least it'd lock the data file when the screen was locked.

From the sounds of it, the thing being protected needs a different type of protection if that many users need constant access to it. Can it not be included into Active Directory or something? With the current setup, the thing may as well have a token password in place since it's only providing an extra sign in step rather than any security benefit.

The program looks like it started in the Win95 Era and has been maintained since then. It might be a possibility, I don't really know who is controlling the password changes. I just know it drives em nuts. They love the interface I wrote, which remembers your login and password for a day, so you don't have to retype it in at every damn use. 100's of times a day.

Some folks are too stupid to realize how dumb and idea that is. The worse part is that quite a few of them work in IT security departments.

Was the program written by a consultant they didn't pay?

I suppose if I had the secret of a working Cold Fusion reactor behind that password it might be worth it. Otherwise, it sounds more like a sadistic prank by the BOFH than useful security.

Though not enough for identity theft.

Below 14 characters (or is it 15), Windows will use NT hashes for storage and transit. Your passwords may also be stored using the stronger NTLM but they are also stored weakly.

At and above 14 characters (or 15), Windows only uses the stronger NTLM hash.

By choosing a 14 character or longer passphrase, you are forcing stronger storage and exchange without relying on if someone has set NTLM only policy in the LDAP.

But it wasn't their windows password, it was the password to the application.

Hence why I have a front end into it, which of course would also require the login and password, but my front end stores it in an expiring local file. Each action from the front end requires you to login. If they use the application directly (bypassing my front end), on every action they have to give it the password again, want information on a person, password, want a summary, password, want to change something, password, want to add someone, password. It's nasty.

"The password might have no LAN Manager representation because the password is longer than 14 characters or because the characters cannot be represented in the OEM character set."

http://support.microsoft.com/kb/102716

sounds like what the police uses...
So that they can tell which cop been snooping around which people's records.

I have two passwords. One is a random 9 character string which I sat and memorised. Oddly, despite the nature of it, Yahoo deems it a low security password... begging the question of what they consider strong, or questions their algorithm for determining such things.
For all financial transactions; EFTPOS, POS, banking s/w, etc, I use a 10 digit number, again of no significance. I DO use a certain number 4 times which can be really frustrating for someone watching - as opposed to what some may think.
Finally, to really upset someone watching you, type in about 6 characters fairly rapidly and hit the backspace key 4 times (so they have to do a sudden 'unmemorise'), only to type the same numbers again. They will almost certainly not realise what you have done, as if done fast enough, they will still be trying to work out which character was wrong. I see this as a simple yet very frustrating way to deter those who snoop.

Strengthen authentication with security token devices or an automatic callback token system.

And make usernames non-trivial ie not variations of the users actual names.

...are obscurity attempts. In true security, you shouldn't accept obscurity as a security method. The idea behind security...what you strive for...is even if I know HOW the mechanism works, if I don't have the proper credentials, I can't get in.

If today's password is known to an attacker then tomorrow's new pwd is far better than today's now ineffective credential.

The forced change mitigates the risk that a password is already leaked and broken. It limits how long a leaked/broken password remains effective. One can use strong passwords with a longer life-span based on the longer time to crack or weaker passwords with a shorter life-span and time to crack. For example; if it takes 30 days to break a password, I want my users changing passwords every 29 days.

Mind you, if you've a different way to mitigate the effective lifespan of a broken password you'd probably answer the prayers of more than a few Admins that don't like forcing 60~90 day passwords.

So you like the trade off of a guaranteed broken password, the one written down on paper right near the computer users machine, to a potential broken password, a strong one that doesn't change very often.

Use time limited passwords and have them written beside the machine and have the hash easily broken.

Use time unlimited strong passwords and have them not written down and potentially not broken.

I don't believe those are the only two options available. Also, my mention of "broken passwords" refers to the planning assumption that passwords have been broken not the expectation that weak passwords are intentionally permitted.

In the first given case, the problem appears to be user training. Demonstrate why passwords written on the side of the monitor are a problem. Given them alternative safe methods for storing passwords. Give them methods for choosing strong but memorable passwords. Give them password managers.

If your password complexity can be broken within 60 days then you need to assume the passwords broken in 60 days and force a change. I'd rather mitigate the potential for an unknown breach in progress rather than clean up after a confirmed massive ongoing breach.

In the second given case, you give an unsafe assumption; that a single strong password remains "potentially broken" rather than "broken" and that no one user among all that share the password can be socially engineered or otherwise leak the password.

First, this relies on obscurity rather than a real security mechanism. It "protects" the system because the strong rarely changing password "feels" safe. The only mitigation provided to protect the system and a leaked passphrase is "shshshs.. don't tell anyone.." which is a strategy consistently proven successful throughout time.

Second, it assumes no user will write down the strong password on a post-it beside the monitor. If anything, user's may be more likely to write down an imposed strong password rather than choosing a more memorable personalized strong password.

How about a third option where strong passwords are used to allow for a longer time to live and chosen by the users given support for methods to choose passwords, store them physically and safely or store them digitally and safely. A few password resets every now and then isn't an issue; if you've got overwhelming reset requests then you may want to look back for gaps in training.

The real solution may be moving to non-password based authentication. So far, nothing has been able to replace the password though.

Maybe something like this, where they pick a memorable password, could even be a name, and then give the users a card, it could be a new card every few weeks if you want. This card shows each letter and a corresponding letter

A=C
B=Q
C=Z
D=9
E={
F=%
Etc

And your real password is what that translates too. Then, the word the user must remember stays the same forever, but they are given new cards. The password is therefore complex against brute force attacks, changing all the time, but the user still only needs to remember 1 word. Even if the attacker were to get a hold of a card, they would still need to know the word the person used.


So my word would be
Slayer

One week that would translate to
&RO@0+

The next week it would be
;uI3Tc

But my word is still "Slayer"

This would make quick changes in over all password policy immediate, with hardly any disruption to the work force!

The last time I worked under HIPAA restrictions, we had a forced password change every 90 days, with a very long pass-phrase. We trained the users on how to formulate their own phrases very easily, and we met with success. Followup supervision proved that it was working. We had few help desk calls, and no breaches from then on.

I like your idea; it would almost be like using a weak form of enigma code.

nt

If it's a strong, unique password, and not written down - how likely is it to be breached? ... in the wild that is, not at a black hat convention.

It depends on a number of things -- like how the passwords are stored, and what defenses keep them from being accessed by unauthorized personnel.

I've heard this argument often, that mandatory pw changes aren't secure. On the surface this can make sense...that users won't create secure passwords and the end result is a more insecure network.

I disagree though, primarily because there is no indication that a user will use a strong password simply because they only have to remember one password.

Additionally, if their account is compromised, and the user is not aware of the intrusion, the intruder has a limited quantity of time to access the network, before the password change is required.

In our organization, we have minimum complexity requirements coupled with mandatory pw changes.

The last pieces for this combination to be secure is 1) disable the "permit credentials to be stored as LANMAN", via security policy and 2) Require user name for authentication and disallow SID identity for authentication. These settings are easy to find Start>secedit>(now look through the settings)

Dumping the SID database is childishly simple and cracking LANMAN is only slightly more difficult.

About 1 week after we implemented a "strong password/frequent change" policy and the users were forced to change their passwords, you could flip over a keyboard or open a desk drawer and find the password for around 80% of the users.

and trained them to use long pass phrases, which were fudged using memory techniques. Everybody seemed to get it; follow up to find sticky notes showed everyone to be clean.

I like Sinister's 'enigma' idea better. I would think it would pass the HIPAA smell test.

Are they all Luddites? Do they hate technology so much?

Why can't people just use password managers? How friggin' difficult can it possibly be?

for Enterprise organizations?

http://keepass.info/

Because it is open source, you can check the code if you want to be paranoid.

Has a random password generator with configurable character classes (to work around system password limitations).

Can be used with a Key file as well as a password for added security (two factor).

Clears clipboard x seconds after use to prevent password hanging around.

It will run off a USB stick and supports a number of platforms:-
- Windows
- Linux
- PalmOS
- Android
- iPhone
- Blackberry
- Mac OSX
- and more..

Unlike many of the newer incarnations of Password managers it does not communicate with the network or synchronise with "Clouds" and for me that's a further assurance.

like the page at your link says; "Yes, it is really free!!!"

Thanks a bunch David!

Try to choose a good password manager , rather than just any password manager.

I can tell you one that I like -- pwsafe with an X integration script -- but that may not serve your needs even though it's open source (and thus free for anyone). Neon Samurai tends to play around with a lot more different password managers, I think, so he might have a better idea.

Pwsafe is OSS with a business use friendly license.


Keepass:
"Is it really free?
Yes, KeePass is really free, and more than that: it is open source (OSI certified). You can have a look at its full source and check whether the encryption algorithms are implemented correctly."
- http://keepass.info/

So, also business use friendly license.


Password Safe
"Oh, and the desktop version of Password Safe is freely available under an Open Source approved license. A disk-on-key version is available here (or here for U3-enabled disk-on-keys) , For customization and commercial support, please contact me."
- http://passwordsafe.sourceforge.net/

A third available under a business use friendly libre license. The developer specifically lists commercial support available by direct contact so if paid support is a requirement, your covered. (I don't think Keepass devs would turn away paying customers either)

Password Safe and Keepass are also written for many platforms so your covered across your systems. In the case of Password Safe, you also have Mr Shneier's recommendation as it's his preferred choice (psh.. like he knows anything about security.. ).

Even works well for sharing a password database between multiple IT staffers.

It's worth noting that pwsafe is designed to be compatible with Password Safe, too, so that the same password database can be used by either of them.

I had Password Safe on my desktop and Maemo device. The desktop version was updated with a newer database format so no more sharing data file between desktop and palmtop; enter, KeepassX. I expect the little builds of Password Safe have since included the newer data format.

Very nice that it's common between pwsafe and Password Safe though. I really should try opening my data file with a few different front ends to see what happens. It may turn out that Keepass and Password Safe read each others bits now. (which would be a mindblowingly awsome)

I'm considering this now, but the whole "all-eggs-in-one-basket" thing worries me.
I just wonder, if I have all my pwds in my head, and they're not so great or I'd have trouble remembering them, sure - they can be breached.
But my computer can be breached too, so it becomes very difficult to evaluate the differences in risk...
Do you know how secure password managers are?

I'm actually inclined to use the soviet spy model. Use a physical book, and just write up the coords for the password (page, line, word). It maybe less user friendly than a password manager though. And I don't have to worry about cleaners, either.

The relative security of a given password manager relies largely on three things:

1. the password manager's design

2. the security of the platform where the password manager is used

3. the user's practices

Some password managers are, in and of themselves, quite good. Some others are quite . . . not. For the most part, password managers based on Password Safe (such as pwsafe) tend to be on the very technically secure end of the spectrum. To help you evaluate a password manager, I recommend you start by checking out the five features of a good password manager listed in an earlier article of mine.

I know you're using MS Windows, which means your password manager is probably running on a platform whose security is mediocre at best -- but using a password manager will not make this any more of a problem than it is already.

In fact, thanks to the specificity of requirements for malware writers and malicious security crackers to compromise your specific password manager setup, there is likely to be a (slight) boost in password security even on MS Windows if you start using a good password manager. Just don't store passwords for more-secured systems that you do not normally use from within the MS Windows environment there, or you'll end up weakening the security of those other systems.

As for your personal practices, that's entirely up to you. Overall, however, the "all your eggs in one basket" objection does not really apply to the security of a password manager, since the real "basket" in this case is your OS, and all your eggs pass through it anyway. Worse, most of them surely pass through the browser, which narrows the specific application within your OS that gets most of your password traffic down to one of the most-targeted types of application on the system.

So, yeah -- as long as you pick a good one, a password manager will likely help.

Keep in mind that using words from a book actually means you're using weak passwords, by the way.

But if I conflate several words, then it should be better.
And I could take an entire line, that'd break the 14 char cap too.
But I will look into getting a good pwdmngr... Thanks!

I'm not sure about Password Safe but other's have browser plugins or password popups.

Basically, when I use the Ironkey password manager, it adds a button bar to my browser which, according to ducmentation, copies the username/password from the manager to the input fields in a secure manner (I think it whipes the memory after though not sure what it does for sniffers).

When I have the Ironkey in and click on any password field, I also get a soft-keyboard pop-up. This is designed to negate keyboard sniffers of various types by keeping my input separate from the standard "bugged" input paths.

There are probably still ways to trap the information during input but that at least helps to mitigate the common methods.

I have not actually looked very closely at how Password Safe itself moves data. I know you can use the clipboard to move authentication data from it to wherever you need to enter it. I suspect that if you use the tool's facilities for interacting with the clipboard it will clear the clipboard after use somehow, but I do not know this for sure.

As for the compatible pwsafe (for Unix-like systems only), however, I know a bit more about how it works. It loads your authentication data into the clipboard and primary selection; you can then copy from the clipboard or paste with a middle-click. It uses secured memory and, when you paste from the clipboard or primary selection, that is wiped -- there is no longer a copy of your authentication data in memory to be pasted.

With my keyboard shortcut hack for authentication data retrieval, an XTerm is opened with a prompt for a keyword that identifies the authentication data you need right then. Type that in, hit Enter, and it hands off control to pwsafe itself so that any further interactions are entirely managed by pwsafe, ensuring that the security software handles the most security-sensitive parts of the operation. No passwords pass through my X integration script.

Because I'm using XTerm as the terminal emulator, I have access to the secure input functionality of XTerm that cuts off keystroke loggers and the like at the knees. All in all, it seems to be a pretty secure password management system. My only complaints at this point are that I would have designed the interface of the core tool (pwsafe itself) slightly differently and I would have released it under a copyfree (rather than copyleft) license. Of course, every application in the world probably has some interface design decisions that pretty much everyone wishes was slightly different, so I'm not sure that's really much of a complaint in this case.

a devil's advocate.
After all, we know the criminals are looking at this too. Cracking a pwd manager would be an orgasmic buzz for them... they'd get instant access to all they need to get into some very high-sensitivity accounts, and they wouldn't even need to guess at what goes where...

Password managers should absolutely be assumed an active target. From the user perspective, that's why I look at how the data file is stored.

Locknote; very nice little "encrypted notepad" but I'm not going to assume it's a secure vault of data. Data is stored back into the .exe itself and I'm not sure the encryption is very strong. I don't remember it having a large password field and it doesn't support certs and such.

Keepass; data file encrypted by AES. The weak point is my passphrase/cert. Until a reasonable cryptographic attack against AES is discovered, my responsibility is to keep the cert safe or passphrase strong and unwritten.

Managers build into the browser may be questionable or less effective than an app dedicated to password protection and management. Check Nirsoft and you'll find rippers for passwords in several different apps; browsers, email clients, Windows base system.

If the manager only offers DES data file encryption, you may want to look for alternatives (I think triple-DES is still good though).

I'd equate the risk to your SAM or shadow files; a criminal taking a copy home to hammer on with brute force and any other cracking method. I need to keep Shadow and SAMs protected to hopefully prevent a criminal from getting a copy. I need to keep my pw manager data file protected to keep a criminal from getting a copy. That's also why my first comment included the mention of combining manager and secure USB of some sort; if someone can get into my Ironkey without self destructing then into my AES encrypted database, I probably wasn't going to stop them without locking it to the wrist of an armed gaurd.

which no one seems to; and you trust LastPass server security; you passwords are never stored on the PC, so they can't be pwned that way anyway.

However this won't stop key-logging in the browswer SSL session. Keyscrambler tests out pretty good on this note. Or at least they convinced me.

I have decided to put my eggs in the basket with LastPass. Time will tell if it is a mistake or not. I figure they are doing a better jog watching their host intrusion system than I am.

I used to think the risk of password guessing programs very small, until we had "qazwsxedc" guessed on a development system (along with "guest" on a "public" workstation)

Some of the ones used by real-life accaks are surprising:
http://andrew.triumf.ca//ssh_pass_file2.html

I'd like to see a more up to date list as that one is 2009. I'm also a daily visitor to the SSH password cloud site. A good uname/passwd list is a thing of gold.

Granted, with programs for generating wordlists these days.. one can build target specific lists pretty easily. I know of one utility that will double all the words along with the regular munging like swapping letters/numbers and such.

I'm not interested in filtering and extracting the log files to do so, but you could. My home system just has SSH open to the Internet and attracts around 300 attempts a day. That's been going on for about the last 4.5 to 5 years, when that sort of attack started to ramp up.

Of course, userid/password login is disabled, as is root login. Login is only permitted using specifically configured accounts for remote access. Concurrent sessions are limited to two and retries per session limited to 1.

300 attempts a day.. damn.. there is no reason to subject yourself to that kind of grief unless the attempts are desired.

Have a look at your firewall settings and limit port 22 to known source addresses. If it's a static IP allow from that IP. For me, this is work; the IP isn't going to change. If it's a dynamic IP then allow the minimum range to catch it. For me, this is friend's houses where I can allow only the dynamic IP range they exist within. If someone else hammers me from within that IP range; they are local enough to speak with the ISP for an effective outcome. When away on vacation, I'm not going to know what IP the hotel's network comes out of; vpn into work, ssh from work into home, set rule based on whatsmyip.com and a comment so I know which rule to remove later.

I'd also suggest you look at fail2ban or a similar program to watch failed login attempts and block the IP in response.

Limited to permitted only accounts, limiting login attempts, allowing cert login only.. these are all good steps.

It strikes me now at the end that you have multiple users who may be connecting from unexpected IP sources. Can you at least limit the allowed IP range to the country or similar?

I do keep a list of IPs, unames, passwd and such. If the attack apears to be using a list I don't have then I may take the time to harvest it out of the logs. It's mostly IPs I collect myself though. Collected uname/passwd tend to be trophies I've popped. General wordlists and default uname/passwd lists are available already.

This is also a good site..
http://www.dragonresearchgroup.org/insight/sshpwauth-cloud.html

.. If your looking to audit for popular picks