Choosing Secure Passwords

Ever since I wrote about the 34,000 MySpace passwords I analyzed, people have been asking how to choose secure passwords.

My piece aside, there’s been a lot written on this topic over the years—both serious and humorous—but most of it seems to be based on anecdotal suggestions rather than actual analytic evidence. What follows is some serious advice.

The attack I’m evaluating against is an offline password-guessing attack. This attack assumes that the attacker either has a copy of your encrypted document, or a server’s encrypted password file, and can try passwords as fast as he can. There are instances where this attack doesn’t make sense. ATM cards, for example, are secure even though they only have a four-digit PIN, because you can’t do offline password guessing. And the police are more likely to get a warrant for your Hotmail account than to bother trying to crack your e-mail password. Your encryption program’s key-escrow system is almost certainly more vulnerable than your password, as is any “secret question” you’ve set up in case you forget your password.

Offline password guessers have gotten both fast and smart. AccessData sells Password Recovery Toolkit, or PRTK. Depending on the software it’s attacking, PRTK can test up to hundreds of thousands of passwords per second, and it tests more common passwords sooner than obscure ones.

So the security of your password depends on two things: any details of the software that slow down password guessing, and in what order programs like PRTK guess different passwords.

Some software includes routines deliberately designed to slow down password guessing. Good encryption software doesn’t use your password as the encryption key; there’s a process that converts your password into the encryption key. And the software can make this process as slow as it wants.

The results are all over the map. Microsoft Office, for example, has a simple password-to-key conversion, so PRTK can test 350,000 Microsoft Word passwords per second on a 3-GHz Pentium 4, which is a reasonably current benchmark computer. WinZip used to be even worse—well over a million guesses per second for version 7.0—but with version 9.0, the cryptosystem’s ramp-up function has been substantially increased: PRTK can only test 900 passwords per second. PGP also makes things deliberately hard for programs like PRTK, also only allowing about 900 guesses per second.

When attacking programs with deliberately slow ramp-ups, it’s important to make every guess count. A simple six-character lowercase exhaustive character attack, “aaaaaa” through “zzzzzz,” has more than 308 million combinations. And it’s generally unproductive, because the program spends most of its time testing improbable passwords like “pqzrwj.”

According to Eric Thompson of AccessData, a typical password consists of a root plus an appendage. A root isn’t necessarily a dictionary word, but it’s something pronounceable. An appendage is either a suffix (90 percent of the time) or a prefix (10 percent of the time).

So the first attack PRTK performs is to test a dictionary of about 1,000 common passwords, things like “letmein,” “password,” “123456” and so on. Then it tests them each with about 100 common suffix appendages: “1,” “4u,” “69,” “abc,” “!” and so on. Believe it or not, it recovers about 24 percent of all passwords with these 100,000 combinations.

Then, PRTK goes through a series of increasingly complex root dictionaries and appendage dictionaries. The root dictionaries include:

  • Common word dictionary: 5,000 entries
  • Names dictionary: 10,000 entries
  • Comprehensive dictionary: 100,000 entries
  • Phonetic pattern dictionary: 1/10,000 of an exhaustive character search

The phonetic pattern dictionary is interesting. It’s not really a dictionary; it’s a Markov-chain routine that generates pronounceable English-language strings of a given length. For example, PRTK can generate and test a dictionary of very pronounceable six-character strings, or just-barely pronounceable seven-character strings. They’re working on generation routines for other languages.

PRTK also runs a four-character-string exhaustive search. It runs the dictionaries with lowercase (the most common), initial uppercase (the second most common), all uppercase and final uppercase. It runs the dictionaries with common substitutions: “$” for “s,” “@” for “a,” “1” for “l” and so on. Anything that’s “leet speak” is included here, like “3” for “e.”

The appendage dictionaries include things like:

  • All two-digit combinations
  • All dates from 1900 to 2006
  • All three-digit combinations
  • All single symbols
  • All single digit, plus single symbol
  • All two-symbol combinations

AccessData’s secret sauce is the order in which it runs the various root and appendage dictionary combinations. The company’s research indicates that the password sweet spot is a seven- to nine-character root plus a common appendage, and that it’s much more likely for someone to choose a hard-to-guess root than an uncommon appendage.

Normally, PRTK runs on a network of computers. Password guessing is a trivially distributable task, and it can easily run in the background. A large organization like the Secret Service can easily have hundreds of computers chugging away at someone’s password. A company called Tableau is building a specialized FPGA hardware add-on to speed up PRTK for slow programs like PGP and WinZip: roughly a 150- to 300-times performance increase.

How good is all of this? Eric Thompson estimates that with a couple of weeks’ to a month’s worth of time, his software breaks 55 percent to 65 percent of all passwords. (This depends, of course, very heavily on the application.) Those results are good, but not great.

But that assumes no biographical data. Whenever it can, AccessData collects whatever personal information it can on the subject before beginning. If it can see other passwords, it can make guesses about what types of passwords the subject uses. How big a root is used? What kind of root? Does he put appendages at the end or the beginning? Does he use substitutions? ZIP codes are common appendages, so those go into the file. So do addresses, names from the address book, other passwords and any other personal information. This data ups PRTK’s success rate a bit, but more importantly it reduces the time from weeks to days or even hours.

So if you want your password to be hard to guess, you should choose something not on any of the root or appendage lists. You should mix upper and lowercase in the middle of your root. You should add numbers and symbols in the middle of your root, not as common substitutions. Or drop your appendage in the middle of your root. Or use two roots with an appendage in the middle.

Even something lower down on PRTK’s dictionary list—the seven-character phonetic pattern dictionary—together with an uncommon appendage, is not going to be guessed. Neither is a password made up of the first letters of a sentence, especially if you throw numbers and symbols in the mix. And yes, these passwords are going to be hard to remember, which is why you should use a program like the free and open-source Password Safe to store them all in. (PRTK can test only 900 Password Safe 3.0 passwords per second.)

Even so, none of this might actually matter. AccessData sells another program, Forensic Toolkit, that, among other things, scans a hard drive for every printable character string. It looks in documents, in the Registry, in e-mail, in swap files, in deleted space on the hard drive … everywhere. And it creates a dictionary from that, and feeds it into PRTK.

And PRTK breaks more than 50 percent of passwords from this dictionary alone.

What’s happening is that the Windows operating system’s memory management leaves data all over the place in the normal course of operations. You’ll type your password into a program, and it gets stored in memory somewhere. Windows swaps the page out to disk, and it becomes the tail end of some file. It gets moved to some far out portion of your hard drive, and there it’ll sit forever. Linux and Mac OS aren’t any better in this regard.

I should point out that none of this has anything to do with the encryption algorithm or the key length. A weak 40-bit algorithm doesn’t make this attack easier, and a strong 256-bit algorithm doesn’t make it harder. These attacks simulate the process of the user entering the password into the computer, so the size of the resultant key is never an issue.

For years, I have said that the easiest way to break a cryptographic product is almost never by breaking the algorithm, that almost invariably there is a programming error that allows you to bypass the mathematics and break the product. A similar thing is going on here. The easiest way to guess a password isn’t to guess it at all, but to exploit the inherent insecurity in the underlying operating system.

This essay originally appeared on Wired.com.

Posted on January 11, 2007 at 8:04 AM169 Comments

Comments

NoOneIsHome January 11, 2007 8:09 AM

Thank you for visiting AccessData Corporation.

Due to technical difficulties, our website is temporarily unavailable.

During normal business hours (8 AM to 5PM, Mountain Standard Time),

our Sales Department can be reached at

800-489-5199

or

sales@accessdata.com

And our Technical Support Department can be reached at

800-658-5199

or

support@accessdata.com

International +1-801-377-5410

Thank You

Randy January 11, 2007 8:38 AM

The phonetic pattern generator seems like a derivative of Morrie Gasser’s 1975 scheme for generating passwords under Multics:

Gasser, M., A Random Word Generator for Pronouncable Passwords, MTR-3006, The MITRE Corporation, Bedford, MA 01730, ESD-TR-75-97, HQ Electronic Systems Division, Hanscom AFB, MA 01731. NTIS AD A 017676.

You can experiment with it at:
http://www.multicians.org/thvv/gpw.html

These roots might make good passwords for your Password Safe.

Jacob Kaplan-Moss January 11, 2007 8:45 AM

Wow, this is excellent – thank you!

One thing you didn’t discuss is the relative security of using pass phrases instead of passwords. My impression has been that since phrases are quite a bit longer than passwords, a passphrase will be more secure. However, a phrase is also much more likely to be comprised of real words… think you could do a quick follow-up and look at passphrases?

WhatAboutLength January 11, 2007 8:45 AM

Great Essay Bruce! However, most of the focus of your article seems to be on password complexity, opposed to password length. I had read that passwords created from easy to remember phrases of 32 characters or longer are much more difficult to crack.

I now always try to use very long passwords (min 32 characters, with “_” replacing the space, and other special characters where appropriate) created from easy to remember phrases unique to me.

The problem I have run into is that for some crazy reason, stupid programmers limit password length/complexity. I was setting up a web account the other day and the site password had to be between 8-12 characters and could only be alphanumeric (the “_” character not allowed, nor any other specials), how crazy/stupid is that.

Dave Page January 11, 2007 8:46 AM

This is why my laptop uses encrypted partitions for swap and /tmp, with the passphrase randomly generated at boot. I’m pretty happy that if anything interesting gets written there, it won’t be recoverable.

(of course, the downside to this is not being able to suspend my laptop, but it’s a reasonable compromise for my purposes)

marc January 11, 2007 8:47 AM

I do not know about OS X (and Windows), but I do know that Linux keeps its swap on a special partition. Seems rather trivial to make sure this is purged at system boot or shutdown, and for added security, it can be encrypted.

I never understood why one would want to have swap encryption, but now I do…

winsnomore January 11, 2007 8:48 AM

This is the kind of thing I read this blog .. keep it up and you’ll ever keep growing.

alabamatoy January 11, 2007 9:01 AM

In a previous life, I was an admin for a Lotus Notes environment. One of its features was a profoundly simple solution to a brute force attack: Each attempt to login was delayed by (some unknown algorithm) longer than the time between the previous two. By about 4 or 5 login/PW attempts, the delay was many seconds and profoundly irritating.

This seemed to me like something that EVERY login/PW system should employ.

Paul Crowley January 11, 2007 9:07 AM

As I’ve said on this blog before, everyone knows the way to choose a totally secure password is to take a perfectly guessable dictionary word, and replace the “o”s with zeros for perfect security.

Milan January 11, 2007 9:09 AM

One issue not addressed above is how often to change passwords. Some of the systems I use force changes as often as every two weeks, and forbid the use of the previous five passwords. My solution is to come up with a very strong password to begin with, then use: cycle1, cycle2, cycle3, cycle4, and cycle5 as temporary passwords to let me reset it to where it was.

Corey January 11, 2007 9:12 AM

With a good enough / available enough password safe, why not just go random? I use “Yaps” on the Palm Pilot, and that’s generally what I do for high-security passwords.
Ones I use a lot end up getting committed to memory (like my work login, since I reboot each day (thanks, Windows), and, of course, my password-safe password).

Corey January 11, 2007 9:16 AM

@alabamatoy

Delaying guesses is certainly a good idea, to fight exhaustive guessing from network clients. However, that delay is not inherently part of the hashing algorithm – it’s just a sleep() in Notes’ password-checking code (otherwise it wouldn’t be variable). Therefore, if someone gets their hands on the hashed passwords and knows the hashing algorithm, they can guess as fast as they’d like.

Bruce Schneier January 11, 2007 9:18 AM

“However, most of the focus of your article seems to be on password complexity, opposed to password length.”

Well, it’s both. Some of the dictionaries have words of different lengths.

Of course longer is better. If you have a 32-character password, no software cracker is going to find it.

Steve January 11, 2007 9:21 AM

Without me making any special effort, I’ve observed that my Windows page file hardly ever moves or extends itself. In fact, this has happened only once. I noticed on the “defrag” display and summary that the file was now fragmented (and larger), so I’d expect to notice whenever it happened.

Assuming I’m right, is it really likely that a swap file fragment will end up in a file, or at the tail end of a block partly used by a file?

I’d expect passwords to be left lying around on disk in the swap file itself, due to applications which don’t (and in fact generally can’t) lock pages in memory, but not elsewhere on the disk.

So why does it happen?

Bruce Schneier January 11, 2007 9:21 AM

“One thing you didn’t discuss is the relative security of using pass phrases instead of passwords.”

I meant the term “password” to be general enough to encompass examples both with and without spaces.

Of course stringing together multiple roots is much more secure than a single root. Right now, AccessData doesn’t have any real good way of brute forcing phrases. Sure, there are common phrases in their PGP-specific dictionary, but that’s only a tiny fraction of the possible passphrases out there.

wiredog January 11, 2007 9:26 AM

As I posted on /. a couple days ago:
The longer and more complex it [the password] is, the more likely it is to be written down on a post it stuck to the side of the monitor. Especially if you have multiple passwords on different change cycles. “Must have a capital letter, special character, number, be at least 8 characters long, and change every 3 months” is probably, in the long run, no more secure than “must be at least 8 characters long, contain one or more non-alphabetic characters, and change twice a year”.

I do what Bruce (and others) suggest: A base password, pronounceable but not in the dictionary, with various variants and appendages. The problem I run into is: Which variant and which appendage am I using for which login? The slashdot, and other similar sites (k5, husi, etc.) have the same password as I don’t much care if hte account gets hijacked for a couple days until I can get some admin to fix it. But places I pay for I need stronger passwords for. Plus several passwords (on different change cycles) at work. Plus the root and user account passwords on my Linux box at home.

So, on that box, I have a file which lists all the passwords (or, rather, descriptions of the variants and appendages) I have to remember.

Needless to say, I don’t do online banking, paypal, or e-bay, as each would require a (different) password which would have to be highly secure, but easy to remember.

vedaal January 11, 2007 9:26 AM

there are simple ways to put obstacles in front of phonetic and other dictionary attacks:

suppose someone decided on the following reasonably pronounceable and memorable passphrase:

Eru Splaige Bronwik Flidditch

but

instead of using this as a passphrase,
it is used only as a memory aid,
with the ‘real’ passphrase being
the above (rot+1):

Fsv Tqmbjhf Cspoxjl Gmjeejudi

the complexity can be further increased
by alternating (rot+1) and (rot-1) for each character, capitalizing the second letter of each word,
putting a number instead of a space, in between each word, etc.

vedaal

Carlo Graziani January 11, 2007 9:32 AM

I’m not paranoid enough to mess with this myself. However, it seems to me that the Linux swap problem is easily dealt with in the shutdown script, just after swap has been turned off, by something like

SWAPS=awk '! /^Filename/ { print $1 }' /proc/swaps

[ -n $SWAPS ] && {
swapoff $SWAPS

for sw in $SWAPS ; do
dd if=/dev/zero of=$sw
mkswap $sw

done }

This won’t erase ghost bits, but it should frustrate PRTK-style attacks.

Please note that I have not tested or debugged this.

Matt from CT January 11, 2007 9:42 AM

1) I wonder how many Botnets are put to use not just generating spam & DDOS attacks but doing some password cracking in spare cycles…perfect distributed application…

2) I’d propose it’s safer with passphrases to not use _ and rot1 stuff and the like.

What’s less likely to attract attention when found:
P.O. Box 1000, Worcester, MA 01608
or
P.O._Box_1000,_Worcester,_MA_01608
or
Q.P._qwX_0001,_W0rc3st3r,_NB_o16o8

If somebodies playing around with the page file anyway…I’m going to guess #1 won’t bring any attention to itself like the other two do.

Nor would it sitting on your desktop or a sticky note (as part of a bigger address) attract nearly as much attention as something that “looks” like a password.

Carlo Graziani January 11, 2007 9:45 AM

A useful class of memorable passwords that are difficult to cast as a PRTK-style stereotype is equations.

For the physically or mathematically-minded, they can be very easy to remember. They also make it easy to involve symbols (memorably). And since the notation for terms can have a very broad variation, they are probably not easy to search efficiently. And, there are a lot of them, many of which are quite obscure.

An example from classical mechanics: Hamiltonian evolution with Poisson Bracket notation might yield a password like

dy/dt={H,y}

Considering the possible variations (ydot instead of dy/dt, Heisenberg evolution with commutators, replace y by a Greek letter like Psi, subtract the RHS from both sides, many more) it seems like a losing game to try to create a stereotype search for these. And in this case, obscurity does aid security.

Guillermito January 11, 2007 9:52 AM

Collecting the biographical information is a key point. Some of this information is publicly available, especially when people have websites or blogs. A few years ago, I suddenly realized one day that the “root”, as you call it, of most of my passwords were words that were present on my website (hobbies, names of cities, people, etc) or in old usenet posts. It would have been trivial to speed up any password breaking scheme by building a simple database of all the words I wrote publically on the internet. Needless to say, I quickly changed my strategy for choosing passwords.

Ian Eiloart January 11, 2007 10:00 AM

Does the “secure virtual memory” on OSX not prevent the “Forensic Toolkit” attack? What about FileVault?

FP January 11, 2007 10:02 AM

I don’t get too much concerned about swap files and all the other places where Forensic Toolkit looks. Tools like that require admin access. If a malicious user has admin access to your computer, you’re pretty much screwed anyway, as your passwords can then be recovered much easier through a keyboard or network logger, or through the installation of trojan software.

I guess the only scenario then is when your computer is lost, stolen, or seized.
A bios-level password is probably a good enough deterrent against loss and low-level crooks. Otherwise, you’re dealing with a very determined attacker who probably has more against you than just your hard drive contents.

Fred F. January 11, 2007 10:04 AM

Someone mentioned it but for linux encrypted swaps and tmp take care of a lot of this problems. I think ssh also avoids the swap issue by marking any allocated memory where the key may be as non-swapable. Also there is a LOT of security knowledgeable people looking at it to make sure holes like that are not left out but it is so easy to leave holes. For example some of those password wallets may not be that good at cleaning their left overs. I for example have a list of passwords in a text file that I use pgp to encrypt. If I do forget to erase it then the text file then it goes into a backup tape (oops). Also at that point a non-security conscious program is being used (to read the text file). It is not an easy task.

FP January 11, 2007 10:06 AM

To all who propose replacing “0” with “o”, space with “_” and the like: I guarantee you that simple substitutions like that are among the first things that tools like PRTK test for.

Mike La Spina January 11, 2007 10:09 AM

Lets face it no password is strong even with a human usable expansion of the keyspace.
As processing power increases and hardware based encryption devices make their way to user systems complex passwords become child’s play.
The only relatively strong password is phrase based due to it’s strength keyspace size and even these are subject to collisions.
If it needs to be secure then it must have a two factor component.

Tobias Weisserth January 11, 2007 10:15 AM

Corrections:

“Linux and Mac OS aren’t any better in this regard.”

This ain’t true.

It’s trivial to setup swap partition encryption in GNU/Linux, although I have to admit that I do not know any vendor that ships this as default. There are several options, I’m using cryptsetup and the aes kernel module.

Since Mac OS X 10.4 swap file encryption is available as “Secure virtual memory” in the Security Pane of the System Settings. If you boot into single user mode, mount / rw and then delete /var/vm/swapfile*, there are no remains of the old unencrypted swap files. Just reboot and new swap files will be encrypted. Again, this ain’t the default setting but it’s enabled with a click of the mouse.

Chris January 11, 2007 10:17 AM

Another problem occurs in the programs: It is not the complete password, which is used, sometimes only the first 8 or 10 characters. This is also something, what needs to be kept in mind.

Alex January 11, 2007 10:22 AM

There are programs that run on Windows that can periodically erase unused portions of the disk. While not foolproof it would help with wiping out old sectors of the page file.

Aaron January 11, 2007 10:22 AM

For most of what I do, the password I use is irrelevant. I do not care if someone hacks into my email account – there is nothing in there that would accomplish anything for them. I don’t keep emails with sensitive information. Same with message board accounts. I use the same password for all of them, and it’s not all that secure. It’s not an English word, but it’s also all lowercase and all letters. The key here is, if someone stole that password, they could post on a message board as me, and I would lose exactly no sleep over it.

For my root account, however, this is not the case. I have a very associative memory – if I’m in a place, I can remember what I did in that place. To create random passwords, then, I sit at my desk, and choose three objects within easy sight (usually words from a book title), then scramble them and string them together. As I am the owner of my own mind, when I forget my password, I sit at my desk, see the same books and remember what I did with those words.

For moderately secure passwords, I use thematic randomness. For example, in the past I used the phrase “dogs bark” as the basis for a password, which when it needed changing became “cats meow” and so on for various animals and the sounds they make. The actual password would look something more like, d0Gzb4rK, but I could remember it simply by remembering what animal was involved. It’s pretty easy to remember that this month is dog month.

Richard January 11, 2007 10:23 AM

I love the way that when there’s an error on a security firm’s site, it gives a convenient error message like:

[Macromedia][SequeLink JDBC Driver][SequeLink Server]Required user name is missing.

The error occurred in D:\websites\global\cfml\tags\mysql41\mysql41-systemsettings.tag: line 36
Called from D:\websites\global\cfml\tags\SystemSettings.cfm: line 193
Called from D:\websites\public\wwwroot\Application.cfm: line 144
Called from D:\websites\global\cfml\tags\mysql41\mysql41-systemsettings.tag: line 36
Called from D:\websites\global\cfml\tags\SystemSettings.cfm: line 193
Called from D:\websites\public\wwwroot\Application.cfm: line 144

34 : value
35 : FROM system_settings
36 : WHERE distribution IN (‘G’,’#attributes.APPID#’)
37 : ORDER BY name, value
38 :

SQL SELECT name, value FROM system_settings WHERE distribution IN (‘G’,’P’) ORDER BY name, value
DATASOURCE AccessData

Milan January 11, 2007 10:24 AM

Tobias Weisserth,

How much of a performance hit does using secure virtual memory involve? That is why I don’t use full disk encryption already.

Aaron January 11, 2007 10:25 AM

Additionally, it might be useful to allow a less secure message board account to be provably stolen.

That way, if some future boss sees your name tagged on something s/he doesn’t like, you can say “yeah, my password got stolen, just like it did this other time.”

Plausible deniability, baby!

Paeniteo January 11, 2007 10:31 AM

@Milan: “How much of a performance hit does using secure virtual memory involve?”

Typically, the performance degradation is rather low. In many cases, when booting the OS or swapping to disk, the bottleneck is not CPU power but harddisk transfer bandwidth, so the the CPU is mostly idle anyway. Why not let it do some encryption?
There is no free lunch, however 😉

Joe Patterson January 11, 2007 10:35 AM

The thing that’s fascinating to me is the thought that PRTK is entirely deterministic. So, given some set of restrictions (i.e., max of 32 chars, low ascii only), there is a single “best” password (for this particular attack tool). Moreover, you could use an “easy” target (i.e., old winzip), encrypt it with your password, run this tool against it, and get a general idea of just how strong your password is.

Interestingly, it sounds to me like a combination of two (reasonably long) dictionary words with a small non-alpha infix would survive this attacker fairly well.

Definitely a fascinating article.

Bryan Feir January 11, 2007 10:50 AM

@wiredog:

I do something similar (base password, with variants, though I use an infix variant rather than prefix or suffix). I don’t write down the passwords: instead I use the name of the machine I’m connecting to as a selector for the suffix. So, for example, I’ll have a six letter base password that is in characters 1,2,4,5,7, and 8; then take the two characters that best describe the site I’m connecting to (e.g. initials of the first two words of the company name), rot13 that (which I can do in my head), and then insert those in characters 3 and 6 of the password.

I don’t know of any automated attack program that will get this. The main weakness is that if somebody gets their hands on two or more of my passwords, they have a chance of reverse engineering the algorithm. And the main advantage is that I can handle it all in my head.

Chase Venters January 11, 2007 11:13 AM

In my opinion, any software that does not take advantage of mlock() in POSIX systems where it is available (such as Linux) is being irresponsible.

Later Linux kernels will actually let non-super-user processes lock, by default, a small amount of memory.

So if you’re going to handle passwords or do decryption, lock the memory to make sure it never gets scribbled to disk.

Does Windows have a similar system call?

Fred Wamsley January 11, 2007 11:16 AM

Diceware ( http://www.diceware.com ) is a great resource for creating passphrases. You get a set of five dice, roll it to get a number like 66315, and look that up in a table of short words. Repeat for each word. You get results like “cleft cam synod yr”, which you can memorize by making up a story about the annual meeting of the bishops of the Church of the Broken Camshaft. A ten-word Diceware passphrase has as much entropy as a 128-bit random crypto key, and even four words is plenty for almost all purposes.

For web passwords, I’ve been recommending a Firefox extension called pwdhash which creates a site-specific password almost transparently.

Is AccessData really and truly selling something you can do in Linux with a single line “strings /dev/hda > /mnt/nerdstick/foo”?

If you want comic relief, I just wrote an analysis of password security at the Hogwarts School of Magic: http://www.berylliumsphere.com/security_mentor/2007/01/excerpt-from-security-analysis-of.html

David January 11, 2007 11:25 AM

@Matt from CT:

There are botnets who’s sole purpose IS to steal user ids and passwords, and any other sensitive data.

I’ve been looking at one since October that has over 40,000 PCs infected. Any login via IE is logged and sent via FTP in great detail (IE 7 doesn’t help – Vista is unknown at this point).

Google: “VBris”.

Grahame January 11, 2007 11:35 AM

@derf

If someone came up to me and offered me a pen in exchange for my password, I’d give them a password too 😉

Just not the one I use. That’s such a dumb survery, I’m amazed.

Davi Ottenheimer January 11, 2007 11:37 AM

Excellent. Reminds me of a couple things.

“…a typical password consists of a root plus an appendage…”

Seems like a shift in the root is all you need to be less predictable. The progression I often have experienced in terms of user password maturity:
1) simple root (password)
2) simple root with appendages (password123)
3) root with character-shift and appendages (p@ssW0rd123!)
4) phrase with character-shift and appendages (e.g. I wish I had a dollar for every star = iW1h@$4e*)
5) random digits generated by a program and stored securely with a level 4 password

To accelerate the progression I’ve found it helpful to send friendly “crackability” ratings to warn people about changing their password. In other words users understood what it meant to get a message from the sysadmins that they were in the 5 minute club. After three violations (three attempts by the user to generate a password that would stay out of the club), a random password would be created by them with some investment in handholding.

I’m also reminded of using secure-wipe shutdown procedures in the late 90s. Systems would take so long to complete their swap clean that it significantly impacted the availability numbers, not to mention increased the frustration of anyone who wanted to do maintenance, etc..

The performance of data destruction thus became as important as the performance risks related to data disclosure/discovery…but you don’t often hear anyone talk about how long it takes a modern system to secure-wipe.

Davi Ottenheimer January 11, 2007 11:42 AM

“AccessData sells another program, Forensic Toolkit, that, among other things, scans a hard drive for every printable character string…”

This is good, but it will only help bypass image-based login prompts if it can also scan for every image file remnant, which most forensic kits do for entirely different reasons.

Bunny January 11, 2007 11:49 AM

Great read.

@WhatAboutLength: that’s not the worst example out there. My bank’s online banking passwords, for example, (which they call “PINs” for some reason, even though they’re not actually numbers) have to be exactly five characters in length – at some time a year or two ago, when they did some internal changes to the system, they also started disallowing symbols (i.e., anything except for letters and digits). Urgh.

The only consolation is that like with real PINs for credit cards etc., you only have a limited number of tries before the system locks you out until you get in touch with them to have your account unlocked again.

Phillip January 11, 2007 11:55 AM

RE: Swap.

If you have a dedicated disk area set up for swap (such as Linux) you can more easily mitigate the swap scan attack.

  1. Hopefully programs you enter a password into lock pages into memory(!!!)

  2. In the likely case that not every program you enter a password into locks pages into memory…if you have a fixed swap space, you can disable swap….let’s say….once a week….run a program like wipe(1) all over the swap partition…and call it a day. wipe -q (4 passes) would work in many cases….it would certainly stop strictly software based attacks.

New Boy January 11, 2007 12:13 PM

Which passphrase below will likely be broken first in real life situation by government agencies?

  1. E5&crW9C@8#x (12 random characters)

  2. aaaaaaaaaabbbbbbbbbbccccccccccdddddddddd (4×10 = 40 characters)

kvenlander January 11, 2007 12:13 PM

I think the reason banks often force you to use alphanumerics only is that you can access your account with phone too. There is no !@$%() etc on a phone keypad.

Rich January 11, 2007 12:14 PM

Some have pointed to studies in which people give up passwords for chocolate, tickets, etc. I’ve always wondered about the real accuracy of those. After all, how to they know it’s a real password?

I’d gladly give someone the password to my bank account for a chocolate. My password is ‘P@55word1’. My SSN? That’s 435-82-4057. No, really, it is. And my DoB? 1/4/1970 for Europeans, 4/1/1970 for Americans. Knock yourself out. And thanks for the chocolate.

Julian January 11, 2007 12:18 PM

It seems to me that a requirement to make a password too strong and change it frequently can be counter-productive. Any process that means you have to write the password down instead of remembering it is going to be less safe.

Neal January 11, 2007 12:28 PM

Haha, before my memory went I used 14-18 digit random number/letter combinations. I could keep about 10 straight, then I’d have to reuse in such a way I could ease the task of associating passwords to uses. Now I’ve got two 10 digit ones that I share between important sites and change once a month. Everything else gets “boobies”

TF January 11, 2007 1:52 PM

Why does any program or operating system allow someone to guess a password 900 times a second? It’s pretty obvious that something doing that is up to no good. The fastest a person could retype a mistyped password is maybe a second. Why not throttle attemts to once per second? I am no geek, so must be missing something here.

peri January 11, 2007 1:52 PM

@Fred Wamsley

I enjoyed the article but thought you might be interested in suggestions for improvements.

*Gargoyles and portraits should be instructed not to accept passwords from clearly unathorized people…

This is an example of the questionable practice of profiling.

*All portals should screen users for traces of Polyjuice potion and evidence of the Imperius Curse

This sounds like “Security Theater.” Consider what happens in the run when you plug piecewise holes. We would still today require that anybody attempting to board a train prove that they are not a witch.

Phil Karn January 11, 2007 2:02 PM

Why bother with swap space at all, much less go to the bother of encrypting or clearing it? RAM is now dirt cheap; just add lots of it and do without swap altogether.

I got rid of the swap partitions on all my Linux boxes years ago, and none have never run out of RAM.

Phillip January 11, 2007 3:42 PM

@TF

“Why does any program or operating system allow someone to guess a password 900 times a second? It’s pretty obvious that something doing that is up to no good. The fastest a person could retype a mistyped password is maybe a second. Why not throttle attemts to once per second? I am no geek, so must be missing something here.”

Yes…I think you are (no offense intended). The “bad guys” have stolen the password database, file, etc. The software (be it O/S or PKZip, whatever) isn’t the thing allowing the passwords to be checked so quickly. “Evil” software (which has legit purposes) especially designed to crack passwords is doing the several (insert your order of magnitude) password cracking attempts per second. Most programs that have a password (My Linux box, for example) won’t allow you to brute force that quickly. On my Linux box, after an unsuccessful login, the TTY Terminal freezes for 3 seconds before you can try again.

The “evil” software is typically ran on a machine other than the one the victim’s.

Hope this helps.

John Ridley January 11, 2007 4:14 PM

I was using mnemonics, but I finally gave up and started using Password Safe, and I use its random generator. If you’re using that anyway, you might as well go fairly long; 16 chars at least. If the program is remembering, who cares how long it is?

Simon January 11, 2007 4:58 PM

I’m clearly missing something but how does Password Safe help? Because it allows distributed passwords to be very strong and all I have to have is one memorable one?

That sounds like a weak spot. Another thing is when away from my computer I’d not know the passwords!

"Anonymous" January 11, 2007 7:52 PM

‘A weak 40-bit algorithm doesn’t make this attack easier, and a strong 256-bit algorithm doesn’t make it harder. ‘

BUT a LONG, LONGER, LONGEST user password DOES MATTER; ~ 40 alphanumerics makes you the 50% uncrackable 🙂

Stefan Wagner January 11, 2007 10:12 PM

I tried:
swapon -s
to find out, where swap is going (/dev/hda8).

Then:
dd if=/dev/hda8 of=/opt/data/swaptest bs=1024 count=172

(only 172K used) – finally:
strings /opt/data/swaptest | grep t0ps3cr3t

No password in swap, but I got too much RAM to be a intensive swap-user, and the machine is just 3 days up (laptop).

Confucious January 12, 2007 12:10 AM

@Aaron
The actual password would look something more like, d0Gzb4rK, but I could remember it simply by remembering what animal was involved. It’s pretty easy to remember that this month is dog month.

The chinese have a similar system, except their passwords are valid for a whole year. 🙂

MacUser January 12, 2007 2:27 AM

@Ian Eiloart

The secure virtual memory option of OS X can offer protection against a password being found in the memory swapfile, but not against it being found in other un-encrypted temp files which may have been created by other applications.

As for File Vault, it only encrypts your Home directory, so various system files and temporary files are not encrypted at all. (Full Disk encryption would be needed for that and there is no FDE available for Mac OS X boot volumes).

In addition, there are a couple of command line tools out there which aim to decrypt Mac OS X File Vault/Encrypted Disk Images.

Anonymous January 12, 2007 3:15 AM

Be careful with long passwords. There are some fsckingstupid** systems out there that will accept passwords of any length during account setup but will only allow entry of notably shorter passwords at login.

For example, one of Dlink’s residential routers will happily accept admin passwords of pretty much any length on the configuration webform but will only actually record 15 characters. Once configured, the router will only accept logins using the 15 character password it recorded. Anything longer will result in an authentication failure. Some vBulletin web boards do similar things.

Bernie January 12, 2007 6:26 AM

Here’s what I’ve been reccommending:

1) Start with a sentence that’s easy to remember. Punctuate it. e.g.
“I’ve seen it, the light! Not you?”

2) Substitute some numbers, e.g.
“1’ve 53en it, th3 l1ght! N0t y0u?”

3) Press the shift key in a rhythm that pleases you for no apparent reason. e.g.
“1’Ve 5£en iT, th3 L!ght! N)t Y0u?”

33 characters, fairly easy to temember, statistically fairly mangled. Also, someone peeking over your shoulder gets confused by the shift key.

solomalee January 12, 2007 7:57 AM

Regarding pass phrases…

And I gseus the arppcaoh of cnahnigg the ceentr lteters aunrod aslo wrkos?

But that’s also a real pain to work out and remember!

PW January 12, 2007 8:06 AM

If you are willing to spend some time memorizing a random password, you can choose a password by dealing out cards with upper and lower case letters and numbers. It’s not that hard to memorize the password, if you make up a mnemonic AFTER you’ve chosen a completely random password.

print your own password cards:
http://www.webplaces.org/passwords/

12 to 15 characters should be sufficient

FP January 12, 2007 10:40 AM

@Simon: “how does Password Safe help?”

It helps in two ways: First, it allows you to choose different passwords for different services. Not many among us can remember 40 distinct passwords; we either have to write them down or re-use the same passwords over and over again, which becomes a nightmare with the different password choice and lifetime policies out there.

Second, it allows you to generate random passwords. Myself, I use different, random 12 character passwords for each service. In cases where I don’t care about identity, I even use a randomly generated user name.

“When away from my computer I’d not know the passwords.”

There’s not many services that I want to use when I’m away from my computer, so it’s not much of an issue for me.

Password Safe and its clones can also be installed on a USB stick, along with the password database. Although I would somewhat hesitate to trust a public computer.

My most annoying experience with a random password was when I called up one service hotline and found that I had to punch my 12 random characters into the telephone keypad.

GeorgeBush January 12, 2007 1:18 PM

Well, now that there is no law, the government does not have to have hundreds of distributed machines cracking.

They can just give you a crack in the jaw and beat the password out of you. Cheaper, quicker, higher rate of password recovery.
And if your a tough guy, maybe they just beat your wife or kids until you crack.

Robin January 12, 2007 1:35 PM

My own personal password system. It seems secure to me, but of course I’m not an expert.

I pick a book off of my bookshelf, and open to a random page. I pick a sentence (usually the first in a paragraph or section), take the first letters, and ‘l33tify’ that, according to various rules I keep in my head. So:

“Now is the time for all good men…”

Becomes:
N17t4agm

Or some such. I dog-ear the page so I can find the original sentence until I have the password memorized.

I find it much easier to remember a sentence than a random jumble of letters, so I think the sentence while I type the password.

With a sufficiently long sentence, the password should be long enough to be difficult to guess. And of course it isn’t based on a dictionary word, either.

TF January 12, 2007 2:48 PM

@Phillip

Thanks for that. And no offense taken, I obviously WAS missing something. But your answer raises the question of how someone without a password can get the password file, and… Nevermind, I obviously have a LOT more reading to do on this…

Shachar Shemesh January 12, 2007 4:42 PM

Linux and Mac OS aren’t any better in this regard.
I don’t know where you got that.
From mlock man page (http://www.opengroup.org/onlinepubs/007908775/xsh/mlock.html)

The function mlock() causes those whole pages containing any part of the address space of the process starting at address addr and continuing for len bytes to be memory resident until unlocked or until the process exits or execs another process image. The implementation may require that addr be a multiple of {PAGESIZE}

So Linux, and it’s highly likely that so does Mac, do have a way for a program to tell the OS “never send this data to disk”. If programs fail to do so, well, programmers are not always as aware as they should.

Shachar

forgetful-not? January 13, 2007 9:55 PM

An interesting blog and many interesting ideas. Many of them do not seem really helpful.
The fundamental flaw in many of the comments above is the failure to consider human factors of typical users. I doubt that I am one, but let me pretend….

Techniques for generating obscure passwords and possibly mnemonics for them are pretty useless in the world I inhabit. I have currently about 30 passworded accounts. Many of these accounts require changing one or more times per year. Ignoring changes, there are 900 combinations of accounts and passwords that I must distinguish, not just 30. I need to recall that for a specific, given account I (last!) used a specific, given password.

I have a hard time remembering arbitrary, albeit mnemonic, strings six to nine months after I last used one. Yet, some of my accounts are accessed only a few times a year (E.g. I change the period on a 12 month CD to take advantage of changing interest rates.).

Moreover, if something goes wrong (e.g. The password I thought I used for this account didn’t unlock the account. Did I mistype the string, use the wrong password for this account, or is the access software itself misbehaving?) panic sets in. I know that if I don’t get the password right in two or three more tries, I’m hosed. I am locked out and must go through a very cumbersome, time consuming, painful process to get the password reset. Usually, access is delayed for days. And that may be to late to meet my need.

In particular, I have been locked out because I used the password for account A when trying to access account B. I remembered the password perfectly. It was just the wrong one. I cannot not have my accounts and passwords written down just because there are times when I confuse password and account combination. And the pain of not getting it right by the third try can be unbearable.

Of course, an alternative exists. I can use the old way: drive 20 miles to the brokerage, when they happen to be open and I happen not to be working and perform the task in person at the counter.

So, I write down my accounts and passwords (in a password safe equivalent: encrypted with a key accessed via a master password ). Because I do not have to remember them in a pinch, I make them long, arbitrary but pronounceable strings. Most of the time I have no problem remembering a password like
ABCm0mVPNm4u, and do not need to access the tool. Only when something goes wrong, but before disaster strikes…..

elegie January 13, 2007 11:49 PM

It has been said that a password can be written to the disk in the form of a memory dump file. After a severe software error, a memory dump file may be automatically generated in some cases. See http://www.truecrypt.org/docs/memory-dump-files.php

For some items of software, a technical report is generated in response to a severe error. The user may be given the option to transmit the report to the software manufacturer for diagnostic and quality improvement purposes. A report of this kind may contain memory contents (and therefore possibly passwords) from the affected software. This issue is mentioned in a security bulletin at http://www.ciac.org/ciac/bulletins/m-005.shtml

Tank January 14, 2007 11:50 PM

“””…a profoundly simple solution to a brute force attack: Each attempt to login was delayed by… many seconds and profoundly irritating.
This seemed to me like something that EVERY login/PW system should employ.”””
Posted by: alabamatoy at January 11, 2007 09:01 AM

This is what I was thinking when I saw 900 guesses/second as an improvement. If you are going to design it to have less than Xmillion/second, why would you allow any more than 1 per second ?
Either you only want humans attempting logins or you don’t.

K January 14, 2007 11:58 PM

“The secure virtual memory option of OS X can offer protection against a password being found in the memory swapfile, but not against it being found in other un-encrypted temp files which may have been created by other applications.”

In order to write out your password, an application first has to read in your password, which requires you to type in your password, which should be a red flag. A more likely compromise is the “safe sleep” file, which can be disabled. See the second post by Travis Beals at:
http://www.macintouch.com/readerreports/security/topic4307.html#nov02
There is some technical discussion after that.

“In addition, there are a couple of command line tools out there which aim to decrypt Mac OS X File Vault/Encrypted Disk Images.”

“Aim to decrypt” is a long way from actually decrypting. As far as I know, the weakest links are the user and master passwords and then RSA-1024.

Philippe Oechslin January 15, 2007 9:16 AM

In your text on password cracking, you say that bruteforcing has nothing
to do with the key length and the algorithm used. You also cite a
cracking speed of 350’000 per second for office documents.

Now since Word and Excel encryption do not use salt, we have been able
to create rainbow tables for cracking of those documents. By default the
password is hashed (with salt), truncated to 40 bit, hashed again (with
no salt) and used for RC4 encryption. By using some known plaintext in
Word and Excel documents we are able to crack any password in 5
minutes with 4GB worth of tables and 99.7% success.

This is a hopping 3’665’038’759 keys per second.

So the algorithm does make a difference when brute-forcing a password.

BTW, the product is called ophcrack_office, its a cousin of ophcrack (http://opchrack.sourceforge.net)

Callum January 15, 2007 11:57 AM

Alabamatoy, Tank, and others have made comments along the lines of “every application should only allow n logins per second” and express confusion over why any app would accept hundreds or thousands of login attempts per second.

You’re missing the point — you need to differentiate between the application and the algorithm.

The application should, quite reasonably, artificially limit the number of attempts, IMO to probably 2 per second.

The algorithm at the heart of the application’s encryption scheme however can be computed much faster — in a thousandth or a millionth of a second.

The baddies aren’t brute forcing the application — they’re brute forcing the algorithm.

Therefore there is great value in making the algorithm intrinsically slow & complicated — it limits the performance of attacks against the algorithm without having a significant impact on the lgitimate end user (assuming yours isn’t one of the (relatively few) systems that actually does need to (legitimately) handle hundreds or thousands of authentication attempts per second).

Callum January 15, 2007 12:28 PM

After having seen too many passwords with matching suffixes/appendages, something I’ve come to consider as a weak string and added to my “not as secure as you think it is” spiel in my security presentations:

any even number 28-44 followed by A-E

including AA & DD that’s a paltry 63, and I must have seen it appear at the end of at least two dozen passwords over the last few years.

Jesse Weinstein January 15, 2007 4:01 PM

Bruce — I’d be curious about your thoughts on Diceware. I presume you agree it makes secure passwords, but are there circumstances where you would advise against using it? Is there a reason you didn’t mention it in the article?

Platter Scatter January 15, 2007 6:52 PM

@Bruce

Thanks for a very interesting article.

“AccessData sells another program, Forensic Toolkit, that, among other things, scans a hard drive for every printable character string …”
“You’ll type your password into a program, and it gets stored in memory somewhere. Windows swaps the page out to disk, and it becomes the tail end of some file.”

I can set my Windows machine to wipe the page file at shut down and use a simple VBScript to overwrite free space by writing a huge text file to disk until the disk is full but I hadn’t considered the leftover data at the end of a file a problem until I read your article. The unused part of a file at the end of a file system unit of allocation seems to be called “cluster tips” or “slack space” by most pages I came across.

After a bit of sniffing around the web, I came across an open source tool called Eraser that claims to erase file cluster tips and overwrite the deleted file metadata with useless rubbish as well as many other useful disk erasing capabilities. The ability to overwrite cluster tips and old file system metadata seems to be fairly unusual, even among the commercial offerings.

http://www2.slac.stanford.edu/comp/winnt/software/Eraser/Securely_Removing_Data_with_Eraser.htm

My tests with another free software utility called “Restoration” seem to confirm the metadata deletion capabilities but it’s hard to be sure about cluster tip erasing (more time and effort needed). My testing was done on a system with standard NTFS cluster sizes and I backed up my data before playing.

It’s hardly ideal but cleaning up the mess left by the OS is better than nothing.

I suggest that anybody thinking of using this tool should work out a data backup method before using the software; it worked perfectly for me but it is important to understand that this tool manipulates the file system at a low level and if it goes wrong your file system may be toast.

Assuming that Eraser works properly, that just leaves the question of orphaned data in the registry. A search of Google using “registry defragmentation” yields loads of software that claims to clean up and optimise the windows registry. I have not tested any of this yet and would appreciate some feedback from readers.

Does anybody know of a good open source registry cleanup tool?

Arun January 16, 2007 12:28 AM

@Bruce: It was an amazing article.

i have some things in my mind.
1. when you say an offline password check, i assume that it works like this:
“the password is never stored as it is. the password when entered becomes a key or is checked against a hash or an encrypted text. the password becomes the key, after some long processing cycle. this processing cycle is a “curtain raiser” against the attack (commented by you, in some articles).” Thus it all depends on the software which takes the password as an argument. The problem may not be with the password, but with the software which uses or checks for the password.

  1. the problem with the password being stored in memory getting swapped or dumped into the file,
    this could be done by the attacker by emulating a “hibernation or page fault”.
    again the software needs to be good enough to rewrite the memory and then delete the pointer, to avoid such an attack.

so basically i would say, a user who is aware of such attacks, even if he takes care by using a 30 byte length alpha numeric character, wont be of much help, if the software is not good enough.

locking the software or web account on 2-3 tries of wrong password is also a solution.

Another doubt: “How does the password breaking software, tries these many times to break the password, if its a web account or a thick client software” ?

Callum January 16, 2007 2:49 AM

@Arun

The assumption is that the attacker (1) has the encrypted passwords, and (2) knows the encryption algorithm. She can then attack the password offline at her leisure.

“so basically i would say, a user who is aware of such attacks, even if he takes care by using a 30 byte length alpha numeric character, wont be of much help, if the software is not good enough.”

Of course, and that’s a key part of the problem — it’s the weakest link that will be attacked, and rather than the password it may be weaknesses in the algorithm, the implementation, the organisation’s security procedures, or the person themselves that are exploited.

“locking the software or web account on 2-3 tries of wrong password is also a solution”

Depends on what you’re trying to achieve — but often a bad idea, as it essentially creates a very straight forward DOS attack.

Grungydan January 16, 2007 11:24 AM

Platter Scatter asked “Does anybody know of a good open source registry cleanup tool?”

Try CCleaner (crap cleaner). It includes a better version of Disk Cleaner that you can configure and a registry cleaner. Seems to work very well for me.

vedaal January 16, 2007 12:35 PM

just some thoughts on thwarting password cracking programs whose strength is high volume checking of passwords/second …

assume an encryption program encrypting a hard disk,

in order to thwart password-checking programs,
the encryption program could do the following:

[1] bind the password entry to to computer clock,
and consider only passwords entered between a selected 10 second interval
(i.e. if the ‘open’ interval is between 20 and 29 seconds of each minute, the computer will consider a password/passphrase whose first character is entered within that 10 second timeframe, even if the passphrase takes longer than a minute to complete,
but it will not accept even the ‘correct’ passphrase if begun outside this interval

[2] allow a pre-determined amount of attempts,
(1, 3, 5, 7, 10, etc.) after which no further attemps are accepted for consideration without re-booting,
but
continue to allow entry of passwords by the attacking program with no indication that they are not being considered,
and sit back and watch the very fast password cracking program continue unsucessfully forever …
🙂

in order for the cracking program to work effectively, it would need to reboot after each attempt, and try each entry six times to get into the ‘open’ time interval

it should slow it down enough so that its capability of checking several passwords/second is defeated

vedaal

Elliott January 16, 2007 12:44 PM

@TF, Tank:

“Why does any program or operating system allow someone to guess a password 900 times a second? …”

I assume you wonder why encryption software does not rehash the password hash in a loop so often that it takes the whole second you suggest.

Yes it would work, given the hash is sufficiently “white” to not degenerate the key space too much during that loop.

But computationally intensive hash loops will take longer on slower CPUs, and put a high load on servers (if useful there) and “windows terminal servers” that are used by many users simultaneously. Hence the vendor cannot make their loop all that hard.

Years or even decades later, everyone use much more powerful CPUs and ask themselves why the loop doesn’t take a whole second as it should.

Jesse Weinstein January 16, 2007 4:38 PM

vedaal — Using the clock is a non-starter, because password cracking programs don’t use the original program, they rewrite the original program’s algorithm, and when doing that, they can easily leave out any references to the computer clock.

Even if the original program was used, it’s not very hard to change the computer’s idea of the time — just keep the computer thinking it’s time to accept another password, and the method is useless.

But thanks for mentioning it, nevertheless.

Arun January 17, 2007 12:18 AM

Reading all the comments, from a programmers end, could any one suggest a technique to raise the curtain against such “Brute force” or “dictionary” attacks.

i will give a brief overview of the strategy i adopt in my existing system.

The password entered is mixed with a “salt”.2 more inputs along with salted hashed password are entered into my algorithm.
this algorithm enters in a loop of 1<n<10 (n being decided first time of registration) and then does some process to give me the key.
this key is used as the 16 byte AES key for verifying my password.
i know its not that safe.

one way to make it safe may be the use of 32 byte symmetric key.
i cant think of any other way ?
do you guys have any idea ? 🙂

JT January 18, 2007 7:43 PM

Hi Bruce, great article, I’m from Australia – can you explain the comment:

“Or drop your appendage in the middle of your root.”

Bruce Schneier January 19, 2007 8:35 AM

“Hi Bruce, great article, I’m from Australia – can you explain the comment: ‘Or drop your appendage in the middle of your root.'”

Do something like: “tipsy.$paisly” or “necess+++arily”.

J Tom Moon 79 January 20, 2007 2:02 AM

Is the following statement correct?
Online logins through https should already be encrypted by the authentication then encryption of communication that takes place before you send your hashed login/password to the server.
So if an attacker only has an ethernet capture of my internet communication, then,
the encrypted channel would have to be decrypted before the password-guessing could be done on the login/password hash.

Does anyone know if the above is correct?
(please fill in reasonable assumptions I may have missed).

To say this in end-user terms,
This password guessing program can’t use password-guessing by-way-of ethernet sniffing to figure out my login to my Outlook web server,
…right?

For me, this is a Windows 2003 Server hosting web based Outlook mail.

Diceware2 January 21, 2007 5:15 AM

The Diceware approach previously mentioned seems (to the untrained consumer) pretty carefully thought out. Could you comment? It still seems reasonable to just use a couple of diceware words separated by symbols or numbers for web logins to email, online banking, etc. Is it? Or should they be longer? Surely the kind of off-line attack your article discusses doesn’t apply in the web world?

Related: To deal with weak passwords, U.S. banks are implementing the curse of the secret question as part of the login process. Your maternal great grandfather’s second cousin’s middle name. Your paternal this. Your best friend. Your favorite book. Don’t make new friends or read new books, it might change your security profile. Paternal, maternal, infernal. Just what is wrong with simply assigning strong passwords or rejecting weak ones instead of forcing us to check ancestry.com to find out how to log on to the bloody bank? Aren’t we all less secure having to keep cheat sheets of all this stuff, and exposing the answers to the bank insiders? After all, about once a week we read another ‘oops, we just leaked all your secret data’ reports. A follow up on secret questions and how consumers can revolt against security tryanny would be nice:)

Erdrick January 21, 2007 5:58 AM

So, what if you were to use a foreign language for your password? I am guessing that most English-speaking hackers/crackers will not be searching through foreign dictionaries to find passwords.

Different name than the others January 21, 2007 6:31 AM

I always drove an unassuming car that looked like it would die. I figured that would prevent theft. 6 weeks ago someone stole an old ugly oxidized cruiser and left a 60 wpc Sansui that needed an output transistor to be worth much more and that shed was wide open.

It WAS cold so I hope the methhead enjoyed how fast they got home that night : )

I don’t do cards, online music DLs for the most part. It’s all semi-amusing and you want to sell a lot of stuff anyway. Everyone needs food, TP and a fleabag motel…no problem with that.

SyPHER January 21, 2007 6:34 AM

I would think a phonetic group like 1 or Alpha and a foreign phonetic pronounciation with numbers replacing the letters in English would be pretty tight. Like @lphaNeHunDapinDun = which would be phonetic for 1st pass and “You’re an idiot” in Mandarin Chinese. You could rotate the @lpha to Br@vo, Ch@rlie etc. But you wouldn’t catch me using that dialect or a password that long..

MikeInPrague January 21, 2007 7:01 AM

Bruce, thanks for the article. A follow-up on what Erdrick asked: I use a hot key to enable my keyboard’s second set of fonts (Czech language) and throw them into the mix, giving things like FuřřýCátIšBa??k for example. Does this actually improve things at all?

Jon January 21, 2007 7:46 AM

Great article. I tend to use a combination of unrealted words, short phrases, name, or partial words (easier for me to remember) and add a date I easily remember. For example – “BillbaseballInformatio12/25”.

What frustrates me is sites that limit passwords to only 6 or 8 characters or limits the characters you can use.

But I suspect, no password is truely safe. I do like how some banks and credit card sites are adding a second password requiremendt or site code.

John January 21, 2007 7:55 AM

Assuming I use the suggestions posted here for creating a very difficult to decifer password, then can I use the same password for all my banking and credit card number containing vendor sites (eg, Amazon) and still remain reasonably safe? Or, is it advisable to create a different password for every such website?

TomD January 21, 2007 8:20 AM

The “Experts” drone on endlessly about the ever increasing power of the hackers, and how many gagilloins of attempts are possible per second. Please tell me why it’s not possible to virtually eliminate this threat by imposing VERY SIMPLE delay countermeasures. The delay has been mentioned, but then we’re right back to the “attack speed” again. Somebody even mentioned a variable delay earlier.

Let’s suppose Windows (Linux, or whatever your favorite OS) imposed a 10 second delay, upon failure, before permitting another attempt. Maybe then a 20 second delay after failing a second time, etc. After (5?) failed attempts, lock the account and reply to any subsequent attempts: “Someone may be Hacking You”. What the heck, once you lock the account after the (5?) failed attempts, you could even continue to act as if you are instantly failing like usual just to keep the PRTK’s busy spinning their wheels [fruitlessly].

I don’t care how many gagillion megaflops and distributed PRTK’s you possess – People could return to “simple” passwords which are possible to remember, and laugh at the attackers. Am I missing something? Why isn’t this delay solution both trivial and more effective than any sort of “password complexity” scheme? (of course Bill Gates would need to be persuaded to add a few lines of code to Vista) 😉

Felix January 21, 2007 8:55 AM

Hey just read the what you said, I have one question? There are some programs that will let you enter spaces in between the your password I have found it very interesting that people will use words symbols numbers but how many actually use spaces I wonder how much more difficult it could be to guess a password if the actual word was a series of spaces ?? with numbers and symbols and letters what is your take on this

Felix D-Cat

Tara January 21, 2007 9:45 AM

@TomD
Sorry, you are missing something. The delay is put in place in most softwares and websites, with appropriate blocks.

As the article states: “This attack assumes that the attacker either has a copy of your encrypted document, or a server’s encrypted password file, and can try passwords as fast as he can.”

So that means that the program (that would normally apply the delays and blocks you mentioned) has already been removed from the equation. This article addresses the problem from that point on. It addresses the question: “What if, somehow, someone gets their hands on the original file?”

Unfortunately, for any system to be secure, the developers can not rely on the idea that “everyone will have to use my interface to try the password” – secure systems take a more pessimistic approach.

Make sense?

Tara January 21, 2007 9:48 AM

@Felix D-Cat

Yes, that’s called a pass phrase and they are much more secure – instead of using a word, you use a sentence. Not all programs support pass phrases, but the more modern ones should.

TomD_Reply January 21, 2007 9:54 AM

“Why isn’t this delay solution both trivial and more effective than any sort of “password complexity” scheme?”

I respect and support your line of reasoning here, TomD, but want to remind you that many hack attacks occur ‘offline’ and so are not constrained by an interface like Windows’ Logon, or AOL’s Sign-On, or WinZip, etc. Rather, the hacker has grabbed a copy of your system’s hash file (e.g. SAM, NT, etc.) and may bash on it freely without restrictions. All the attacker need do in many cases is (trivially) look up and compare your unknown password’s hash (e.g. MD5) against a very long list of hashes for known strings (e.g. rainbow tables). Worse, if the attacker were armed with knowledge of the hashing algorithm of your particular app (WinZip) or possessed a crippled version of the app you propose (his might omit the delays, for instance), he’d still get pretty far. Likewise, the attacker always has the easier option(s): sitting outside your home/office sniffing wireless traffic (until you type your password!); deploying a keylogger on your PC; videotaping your sessions; socially engineering a password reset (by calling your ISP or IT Dept.); blackmailing your vendor/wife/boss, etc.
Back to your initial assertion (with which I still AGREE), why not also have multiple passwords instead of just one? For example, GMail’s welcome screen could challenge you (in a way similar to banks now do) with three password fields, each marked with a predetermined graphic (“guitar”, “ostrich”, “tower”) in random order. Your job at login would be to enter your (three) passwords in the correct order. Sure, it wouldn’t prevent keyloggers or screen scrapers from snagging your info, but it’d go a long way toward stymieing brute force attacks.

Bruce Schneier January 21, 2007 10:22 AM

“The ‘Experts’ drone on endlessly about the ever increasing power of the hackers, and how many gagilloins of attempts are possible per second. Please tell me why it’s not possible to virtually eliminate this threat by imposing VERY SIMPLE delay countermeasures. The delay has been mentioned, but then we’re right back to the ‘attack speed’ again. Somebody even mentioned a variable delay earlier.”

Why are we “experts” in quotes? Do we really not have expertise?

In any case, of course you’re right. Lots of programs have this countermeasure. It works great in systems where only on-line attacks are possible, and are why four-digit PINs are secure in some situations.

The threat scenario I wrote about was an off-line password guessing attack, because that’s the more powerful attack.

There are delay schemes that work here, too, and it’s exactly what I am describing in the seventh paragraph of the essay. Programs like PGP and PasswordSafe have very long password-to-key conversion routines, and that greatly slows down password guessing attacks.

There’s a trade-off between how long the user is willing to wait, though, so we don’t use minute-long conversion routines; 100ms is generally considered to be a good length.

And, of course, these defenses don’t make password guessing attacks impossible, just slower. PRTK still breaks easy-to-guess passwords used in these programs.

Platter Scatter January 21, 2007 12:30 PM

@MikeInPrague

“A follow-up on what Erdrick asked: I use a hot key to enable my keyboard’s second set of fonts (Czech language) and throw them into the mix, giving things like FuřřýCátIšBa??k for example. Does this actually improve things at all?”

It depends upon which Unicode or ASCII characters ranging from 128 to 255 are used.

I am only going to look at this regarding Windows logon passwords; banks and websites will probably be different. Here is a Microsoft article about using Unicode characters in passwords:

http://www.microsoft.com/canada/smallbiz/sgc/articles/select_sec_passwords.mspx

Microsoft’s advice is that some Unicode characters can be used to improve the password strength but watch out – some Unicode characters are automatically converted to standard alphanumeric format when the password is stored. Have a look at the table headed “Recommended ALT Code to Use for ALT Key Combinations”. It seems to me that a half decent password with some Unicode characters thrown in would really screw up attempts at offline cracking.

P.S. I keep intending to load Password Safe and try it but haven’t yet. Does anybody know if Password Safe will handle Unicode passord characters as recommended my Microsoft?

nihilena January 21, 2007 3:43 PM

While I’ve no industry experience or extensive computer expertise to support my assertions, I’ve always assumed that non-qwerty compatible foreign languages like Arabic and Japanese are stronger root sources. Accepted basic variations in English language expression (Allahu Akbar vs Alaahu Aqbar, Shojo vs Shojou vs Shoujo) make simple dictionary attacks ineffective even before you start replacing characters, doubly so if more than one language is represented in the password. Either way, it seems like a rather large contingent of ignorant end-users would make more attractive targets than anyone with a bit of security sense.

David Paul Robinson January 21, 2007 10:29 PM

It’s interesting how really insecure most people are with their own passwords. With the average person signing up for dozens of Web 2.0 services and using the same password on all of them, their chances of simply “giving away” their common passwords are astronomical.

star January 27, 2007 10:22 AM

wow! this is loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong!!!!

Rom February 10, 2007 7:45 AM

This comment by New Boy at January 11, 2007 12:13 PM never got a reply:

“Which passphrase below will likely be broken first in real life situation by government agencies?

  1. E5&crW9C@8#x (12 random characters)
  2. aaaaaaaaaabbbbbbbbbbccccccccccdddddddddd (4×10 = 40 characters)”

Can anyone give a comment on that now? How secure is such a “long password strategy”? Similarly, I’ve seen some people advocate using a long sentence as password. A related strategy would be to repeat a simple word multiple times and then add some other stuff. For example: “soccersoccersoccersoccersoccer$$soccer”. That’s an easily memorized password: 5 soccer, 2 dollars, 1 soccer. But how secure is it?

WeakPwd May 8, 2007 10:00 AM

@Rom @Bruce

It depends what service you are using. As AOL shortens passwords to 8 characters it could easily be found by a dictionary attack. Same for passwords which first 8 characters are in a dic.

Squyd May 11, 2007 11:55 PM

I have the “perfect” way to create virtually uncrackable passphrases.

Step 1. Open any text file of more than 1kb in a text editor.

Step 2. Using PGP or GPG, encrypt the current window of text with whatever passphrase you want.

Step 3. Delete the PGP header and first 2 or 3 rows of text, and the PGP footer and last 2 or 3 rows of text.

Step 4. The result is several rows of seemingly garbled “junk” text. The text has a character-space of 64. (all 10 digits, 26 upper-case, 26 lower-case, “/” and “+”.) Using the formula X^L, where X=character-space and L=length, the total possible passphrases is 64^64, or 3.9402006196394479212279040100144e+115.

Any row can be used as a password. Additionally, you can number these for reference when naming the encrypted file.

The drawback is that you must store this list. However, smart people will encrypt the list itself using PGP or GPG with quite a long passphrase. I use any one of several memorized passwords of 32 bytes each.

The final drawback is that PGP disables the paste hotkey; but GPG does not.

Any thoughts?

Axel May 27, 2007 12:31 PM

Hi out there,

reading this site I finally realized that strong crypto is really hard work to do right. You have to look at the side of the user input and the side of encryption algo. You have to fight against rainbow tables and cracking algos. Ok, I learned and here is my suggestion:

  1. User input

Easy enough to remember but cryptical and long (12-20), trivial things (a1a1a1) not allowed;
i.e. parts of names of persons (Tom Sawyer, Elisabeth Taylor to password ‘ToSawyTayEli’ = 12 parts) and in addition a digit.

Directly depending on this digit internally a part of the password is copied, the string md5’ed (or something else) and inserted within the inner part of the password. Now you have a longer password i.e. with 44 parts (or more), too long for r.t. or other cracking prog.

I assume that even if the ‘inserting’ part of the program code is known, the cracking program doesn’t work because the minimum 12 parts password and the additional possible variations caused by the digit would bloat the number of required loops enormously.

  1. Crypto Algos (Hashes)

In the first step encrypting the 44 parts with i.e. ripemd256 to get an encrypted 64 parts value (now no zero values and so on to weak the encryption). In the second step this value encrypted with i.e. sha256.

Is this the right way to sleep well?

Bye, Axel

PS: I read on this site about tries per second (wow). I assume with the right (big!) hard- and software it is possible to handle the work parallel (one prog opened many times in different caches) and so there is no real limitation by the attacked prog, is that right?

Axel June 8, 2007 9:33 AM

An additional to my last posting:

As I read, one possible weakness in html-forms secured by SSL (normally 128 Bit) could be an attacker listening to always the same input sequence (same plaintext password) in the POST data.

My suggestion: Increasing the (first time empty) input field by some md5-noise (depending on a random number) before user input. Ok, thats not a nice looking input field 😉 Better idea?
At the end, for computing the POST data is read and the noise only had to be cutted.

Bye, Axel

James September 28, 2007 2:04 PM

I’ve read many of the comments but not all so please excuse me if this has already been mentioned.

I’ve always taken a sentence or a few lyrics to a song and then used the first letter of each word as my password, replacing letters with numbers where possible.

Example:

for those about to rock we salute you

becomes

fta2rwsy

This makes a rather obscure password very easy to remember. Of course the longer the better but this is just an example.

Quasibozo September 29, 2007 11:20 AM

All comments are interesting and incredibly estute. However, everyone of you very “heady” contributors fail to factor in the intellect of the average computer user. At what threshold is this too much?

DestroyThe Atackers October 30, 2007 8:36 PM

I think this has been a valuable discussion. And is something we all need to consider.

But when do we come up with a way to fix the original cause of the problem? That is, finding and punishing the criminals causing this problem. How can we (or the Big People at Microsoft, IBM, the ISPs, Apple, Congress, Federal Agencies, the various software/system organizations and geniuses, etc., etc.) track down and prosecute these criminals and vandals? Or at least come up with a reasonable software/hardware solution to prevent these attacks within our PCs?

I know many of these attacks come from outside the United States and that prosecuting those criminals and disturbed kooks becomes harder. Yes, I know these attacks are masked by spoofed IDs, anonymous and hijacked IPAs, etc. And that there are many criminals, vandals, kooks, and jerks committing these crimes.

But it is hard for me to believe that:

First- these criminals cannot be traced, arrested, prosecuted, and punished. Even if this means that operating systems, the internet, local and international laws, and whatever, be modified to accomplish this.

Second- our PCs cannot be protected from these attacks. Why can’t operating systems, the internet, or whatever, be modified to accomplish this? And at no additional or modest cost?

It is time to stop treating the symptoms and to now fix the root of the problem. We need to prevent the creation of cancer.

anjan bacchu December 4, 2007 8:09 PM

hi all,

windows/linux pagefile : I don’t employ the pagefile at all. If you have enough RAM, then you don’t need the pagefile. Although, I am not sure if someone can scavenge from your RAM ? does POST zero it each time ?

BR,
~A

Sherwood Botsford December 11, 2007 12:25 AM

I have this battle with the kids at school where I sysadmin. I gave up trying to get them to create good passwords. Now I make up one, and disable password changing. While they aren’t super strong, they are in a class above ‘klingon’, ‘abc123’ etc.

When I’m setting up accounts in the fall, I run a program that analyzes a block of text, creates a chain what letters can follow what letters. Then it does random passes through this. This gives me mostly pronouceable but not very vulnerable to dictionary attacks. Add a couple of upper cases or a punctuation mark, and it’s done. Typical results:
fliPPleKnip, GarfkNorkit, zurfendlip!!

Nick December 22, 2007 4:22 PM

Is encryption compromised by creating a password of the wrong length, especially if it’s too short, relative to key length?

One writer seems to say that a password character correlates with 4 bits of the key. Is that so? For the following, I generally assume 8 bits per character.

Given that one creates a key when encrypting by creating a password or passphrase, doesn’t that mean that, for example, a 128-bit key requires a 16-byte or 16-character password? If so, wouldn’t diverging from that ratio compromise security? Since the ratio differs on machines using other than 8-bit bytes (e.g., 9-bit bytes), what happens to security if the key length is not an integral multiple of the byte length? And does encryption software have anything to do with byte length?

For a too-short password, 3 choices face the encryption program: (1) Shorten its key length to accommodate the received password. That cuts security inherent in encryption. (2) Pad the password to the key’s length by assigning a character string of its choosing equal to the length deficit. The string would have to be either invariant or generated from the password, but always the same whenever the password was the same as another password, as well as always the same for all copies of the program and all compatible versions and all compatible software (e.g., I don’t recall hearing that one must decrypt 3DES with the same brand of program that encrypted the file). It wouldn’t take long for a cracker to figure this method out. (3) A combination or alternation of the above depending on the password. Combining or alternating would have to be predictable, or decryption would sometimes fail.

For a too-long password, the program’s choices may be less problematic. (1) It can lengthen its key length. Export restrictions limit this option. If the export limit is 56 bits, that’s maybe 7 bytes, and discarding password characters past 7 weakens security. (2) It can discard or ignore part of the password per a consistent scheme. Predictable. Thus, the user’s sense of security from having a long passphrase would be excessive. People induced through social engineering to reveal part of their password (e.g., at work) might be revealing the only part that matters. (In one office, I was given my Windows password by my supervisor and not allowed to change it; I found a way to monitor his frequent entries into my computer, but I don’t know what he was doing there.) Socially engineered revelations are not always due to individual laxity; an institution may impose teamwork obligations that require cooperation. (3) Again, it can combine or alternate protocols, but only predictably.

This also could vary according to the encryption method built in, but if it doesn’t (and if conversion is not part of the encryption method) any weakness here would be multiplied. E.g., if an encryptor program uses one method to convert a password to a key and offers two encryption algorithms, that conversion method would apply to any file regardless of which encryption method was used, and thus the conversion method would have to be shared in common with all software that is encryption-method-compatible for either encryption algorithm.

— Nick

Nick December 22, 2007 4:30 PM

May encryption be compromised by using other than lower 7-bit ASCII for the password because of the conversion to a key?

Encoding variations (UTF-n, ISO-n, & perhaps others) leave me wondering if the same key cap or keystroke combination can be mapped to more than one bit sequence or if multiple keystroke combinations can be mapped to one bit sequence. I seem to have run into discussions about Linux facing this issue. If so, then encryption software that converts a password to a key should accept multiple passwords for the same key or generate multiple keys from the same password. As this is sometimes normalized by geography but encryption/decryption is performed across borders, conversion has to be locale-independent and thus more or less encoding-independent, yet also keyboard-layout-independent (layouts vary by nation, assuming that Dvorak/qwerty doesn’t matter). As I recall, upper ASCII (decimal 128-255 or (hex) 0x80-0xFF) differs markedly between Win and Mac, at least for old Mac like System 6, yet passwords would normally be shared between sender and recipient humans only by stating key cap sequences or key cap combination sequences, especially relevant where user machines are on mixed-OS networks using unknown-OS servers for these functions.

If all encodings agree only on ASCII in which the most significant bit (MSB) is masked, perhaps the most secure passwords should be limited to the lower 7 bits minus control characters (i.e., limited to decimal 32-126 or 0x20-0x7E, constituting alphanumerics without diacriticals and !”#$%&'()*+,-./:;<=>?@[]^_`{|}~ (in ASCII order) (I’m trusting the software where I’m posting this correctly represents those characters but they can be checked in Win’s Character Map set to a common body text font). One writer about Linux filenames argued for using only POSIX-compliant characters for filenames: alphanumerics without diacriticals and – and _ only; perhaps that should apply to passwords, too, if encoding is a problem, but definitely not if encoding is not a problem.

Is any password/key conversion system open-sourced and is that open source conversion system in use in any accepted encryption program? Alternatively, are conversion methods independently analyzed? Or am I wrong that encryption may be compromised by using other than lower 7-bit ASCII for the password because of the conversion to a key?


Nick

Nick December 22, 2007 4:38 PM

What follows re all of above:
— Password Safe: hand-encrypt first
— Password length limits unannounced, don’t give parts
— Password case flattened
— Linux without separate partitions for shadows
— Password randomness, mental entropy, auto-mnemonics
— Passwords necessary, liability for what happens without it

For Password Safe and other password storage programs, for more security, I’d hand-encrypt the passwords as you enter them. You’ll have to decrypt them as you use them (thus barring automatic use or copy-and-paste), and if you need the program as your personal memory jog you’ll probably need a hand-encryption method that’s also memorable even for rarely-used passwords, so you’ll probably want to come up with a method that’s relatively easy to crack, especially if someone cracks one of your passwords and thus sees your re-encryption method. But this is still better than risking someone cracking your storage software on a multicomputer setup, because the cracker is forced into a second step, if it occurs to them, which it may when their first results fail to reveal your secret contents.

Length-limiting of a password is sometimes unannounced. An interface sometimes lets you enter any length you like (at least where I haven’t hit a limit), then the program ignores whatever is past some length limit without telling you. This leads to false security, at least in part. This is somewhat like when people are asked for part of some secret number and they give the part out because they’re not giving the whole thing away, because they don’t realize that the rest of the number can be determined by other means. So the advice about not telling anyone your password, including a password-protected-site owner, applies to parts of passwords, too.

Likewise, case is sometimes ignored or converted (same result), again allowing a false sense of security.

Linux does not always have separate partitions. That varies by distro, unless you go to the trouble of setting up that way despite the defaults in your distro, and setting that up may entail more than partitioning your hard drive yourself, because you may have to convince the installer to put some Linux files on different partitions and then make some partition/s invisible to users, unless you can figure out how to do that yourself. Friendlier distros, in my observation, are less secure and less likely to have second partitions and unlikely to offer an option of second-partitioning explicitly. I’ve seen single-partitioning on a distro with SELinux on, so SELinux is not correlated with separate partitioning, which would still be useful. I think the original Linux has for many years included multiple partitioning but that some distribution programmers disable it in order to simplify users’ installation experiences or to ease coexistence and multibooting with other OSes.

I create a random password or, more often due to lack of time and a spreadsheet when I need a new password (away from home), a mental attempt at a password (remembering that humans have had to try to impose order just to enhance survival since cavedwelling ages and so I have to compensatorily impose disorder from character to character). I don’t worry about long-term memorability, because with use the human tendency to find order will tend to yield mnemonics that aren’t necessarily absurd.

The danger of someone hacking into your email account (etc.) is that they can send emails on your behalf without leaving a copy for you. You may never find out; or someone may reply with unexplained anger at you, for example, or bill you for something you obviously did, since your email authorized it, as far as anyone can see. Likewise for online accounts, forums, etc. I had one vendor shut my account down because they were sending passwords unencrypted over the Internet; although they claimed they couldn’t close the account, their terms said I’d be liable for whatever was bought on it. I persuaded them to shut it down. On a forum, someone can post libels on your behalf and you get the lawsuit. I’m not sure an employer wants to hire someone who explains bad actions by saying their password was stolen. Recommendation: Use secure passwords.


Nick

Life March 26, 2008 11:15 PM

I would like to work has a white Hacker for your company i can hack the US gov. but i don’t do that but I willing to protect what is most valuable to an american individual.

crypto fog April 24, 2008 7:27 PM

New so bear with me. I understand some prog’s like PGP (generated keys) and PGPdisk are fundamentally different in that the PGP disk or vault is accessible independent of having the application. If I e-mail my brother a PGPdisk, I believe the application is built-in and the recipient only has to know the correct phrase/pass. 1) Is this correct? 2) Is such a vault file as secure as an archive encrypted with regular PGP (assume modest key length and, say, a simple password like ” helenismywife”) ? Thanks for all the informative posts.

crypto fog April 29, 2008 5:18 PM

..the no-app needed file is actually SDA self-decrypting archive using PGP. I’m still interested in the relative security of std PGP vs SDA vs PGPdisk. Thx

passwordchart.com August 7, 2008 5:35 AM

I know this post is old, but I found this website that uses a clever way of generating secure passwords from a pair of simple pass phrases.
It hashes the first to seed a PRNG (Mersenne Twister) and then creates an chart where each alphabet letter are mapped to two or three characters generated from the PRNG’s output.
The second passphrase is used to generate the “safer” password by mapping the passphrase to the chart (just like a substitution cipher).

My question is…
Rather than asking if the actual implementation of passwordchart.com is sound, would it be just as safe to take two easy to remember passphrases, one to seed a PSNG and the other to map to the output as opposed to choose a random hard-to-remember password?

Would you trust this method to one of your friends as a alternative to have strong passwords that are easy to remember?

Chuck February 4, 2009 12:11 PM

I use a simple pattern to create a secure password.
Take a date: 19970725

Then enter it twice, one time regular one time holding shift key. But I also hit the letter below the number: 1q, 2w, 3e etc.

So the date: 19970725 becomes

1q9o9o7u0p7u2w5t!Q(O(O&U)P&U@W%T

lower case, upper case, digits, sp. char.
easy to remember, very strong.

Also you can write down your passwords without compromising security.

Bank = Birthday
G-Mail = Anniversay
Amazon = Mom’s Birthday

Ste July 9, 2009 1:14 PM

A good way to turn a simple phrase into a tough password to crack is to join the two words as so. If you were to choose the phrase “yellow banana” – it would come out like “ybealnlaonwa” – now that’s secure, and if you add a couple of numerical digits on the end you have your password.

James November 12, 2010 8:33 AM

I always use a random password generator for my passwords. It makes it harder for me to remember, but I normally have them saved in my browser. It makes the my accounts much more secure though.

PT November 18, 2010 7:17 AM

A bios level password will not protect the hard disk(s), which can be physically removed and attached to another computer for reading.

osatuyi oluwasola January 4, 2011 5:09 AM

bruice
pls i need a detailed information on the various methods of password recovery (both the secured approaches and the insecured approaches), the problems associated with them and the possible solutions you can give as suggestions.
thanks

DZ May 8, 2011 2:35 AM

Pick a password using things and relationships from the environment as this stuff totally defys logic. Don’t use mental constructs (logic). Scientists all over the world study the environment to obtain its secrets. You can’t just sit in a chair and think.
Intelligent behavior is consistent, purposeful, and always has a reference point.
The weakness of intelligence is that intelligent people act intelligently. Sadly, they can be captured by other intelligent people.

Woof May 31, 2011 2:17 PM

Regarding the method of scanning the hard drive for password clues, how effective is using disk encryption software (e.g., TrueCrypt) against this type of attack? Does the swap file data get encrypted?

Ol'Duffer September 12, 2011 7:25 PM

With Graphics Processing Units (GPUs) able to run parallel bruteforce, how much longer will passwords be a viable security feature?

Mr. Ultra-paranoid September 17, 2011 4:11 AM

TrueCrypt can encrypt as much of the hard disk as you like: Full-disk encryption is best. Note that TrueCrypt is vulnerable to Evil Maid attacks, so physical security is still very important.

GPUs can be used in parallel to attempt to crack passwords very quickly and inexpensively, but a long, random password is not the lowest barrier to entry (yet).

For accounts you care about:

<

ol>

  • Use a password safe. This is basic, entry-level security.
  • Don’t use it anywhere but on your own computer. It takes 12 seconds for a random person to install a hardware keylogger on a public computer, and you really can’t know what spyware the owner of the computer has set up (e.g. archive the contents of every USB stick inserted).
  • Set up as much security on your computer as your expertise and hardware will allow. This is difficult, and still an area of active research. Full-disk encryption is a start.
  • aussieaussieaussieoioioi June 9, 2012 1:59 AM

    Is it just me that found the Aussie above (and Bruce not getting it) hilarious?

    shankar October 15, 2012 1:54 PM

    Hi,
    I use the following small php program to generate unique password for every site. I would like your thoughts on it.

    <?php
    if( $argc!=3 )die( "usage conv <file> <rot1>" );
    $st = $argv[1];
    $len = strlen( $argv[1] );
    $rot = $argv[2];
    if( !preg_match( "/^[0-9]+$/", $rot ) )die( 'rot must be a number' );
    $extra = strlen( $rot );
    $vals = array();
    for( $i=0;$i<$extra;$i++ ){
        $val = ord($rot[$i])-48;
        $vals[$i] = $i%2 ? -$val : $val;
    }
    function rot( $ch, $inc )
    {
        $ch = ord( $ch );
        if( $ch>=97 && $ch<123 ){
            $ch -= 97;
            $ch += $inc;
            if( $ch>=26 ){
                $ch %= 26;
            }else if( $ch<0 ){
                $ch += 26;
            }
            return chr( $ch+97 );
        }
        return chr( $ch );
    }
    for( $i=0;$i<$len;$i++ ){
        $val = $vals[$i%$extra];
        echo rot( substr( $st, $i, 1 ), $val );
    }
    ?>you use it like:
    php word.php word scramblingnumber
    suppose the site is mail.yahoo.com I type
    php word.php mailyahooshankarcom 298347932384
    

    I use the same scrambling number for every site simple to remember yet no one can guess it.
    Also the password or scrambling number is not stored anywhere.
    What do you think?

    shankar November 12, 2012 7:36 AM

    Actually you have to replace the first few lines of my php program with:

    if( $argc!=2 )die( “usage conv ” );
    $st = $argv[1];
    $len = strlen( $argv[1] );
    echo “Scrambling Number: “;
    $rot = trim(fgets(STDIN));
    if( $rot==” )die(”);

    Because otherwise if the scrambling number is taken from the command line it will be stored in the history file in linux systems.

    shankar November 12, 2012 7:47 AM

    Or better still with:

    echo “Word: “;
    $st = trim(fgets(STDIN));;
    $len = strlen( $st );
    echo “Scrambling Number: “;
    $rot = trim(fgets(STDIN));
    if( $rot==” )die(”);

    so that even the site name is not stored in the history file.

    white wines April 16, 2013 3:46 PM

    you are in reality a good webmaster. The website
    loading speed is incredible. It seems that you’re doing any unique trick. Furthermore, The contents are masterpiece. you have performed a magnificent activity in this topic!

    Leave a comment

    Login

    Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

    Sidebar photo of Bruce Schneier by Joe MacInnis.