PINs (not "PIN number," please) are often chosen poorly. Among the most common PINs are "0000" and "1234"... in fact over 10% of PINs are 1234, seriously?! Your pin doesn't have to be weapons-grade-cryptography ready (it can't be, anyway) but it should be less guessable than Mel Brooks' luggage combination.
To that end, I present you with a most helpful resource: the Unicode PIN mappings. These are characters from the international Unicode set (the way computers store characters from nearly every language on Earth) that have a four-number representation that you can use in a PIN code. Since many Unicdoe characters either aren't actually characters (things like an umlaut that only have meaning when combined with another character, or "non-printing" characters like a non-breaking space which are used in formatting) I've pared the list down to just the ones that have some basic visual representation. Also, the codes for Unicode characters are most often (and here) represented by what's called "hexadecimal" notation, so I've removed all of the ones that contain letters in that representation.
What you're left with is pure gold for selecting and remembering a non-obvious PIN. If you ever forget your PIN, then a quick Google search for the name of the symbol plus "unicode" will turn it up in no time. A few examples from the big list:
! (EXCLAMATION MARK) 0021
⁇ (DOUBLE QUESTION MARK) 2047
™ (TRADE MARK SIGN) 2122
↑ (UPWARDS ARROW) 2191
☁ (CLOUD) 2601
☂ (UMBRELLA) 2602
✡ (STAR OF DAVID) 2721
け (HIRAGANA LETTER KE) 3051
Showing posts with label security. Show all posts
Showing posts with label security. Show all posts
Saturday, March 5, 2016
Saturday, August 13, 2011
Passwords and XKCD
I feel as if I'm walking into a trap. Randall Munroe is sort of a folk hero among geeks, and when I saw his recent comic about password strength, I was, at first, thrilled. Here's someone who knows how to communicate to the masses exactly what they need to know: they choose poor passwords, and could just as easily (or easier) choose strong passwords that they could remember.
I understand where he's coming from, and he's right on some level, but let me explain to you what the layman heard:
If your password is a space-separated list of four English words, no one will ever be able to crack it!
Sadly, there's even solid proof that that's the case. Here's the first example I've seen of a "password" generator based on his approach: XKCD Password Generator.
All I can say is /facepalm.
OK, so those of you who might not get what's going on, here, this is what he's saying:
When you try to make a very strong password, your first inclination is often to try to maximize the complexity of the password from a human perspective. This works very well if you're willing to memorize, say, 13 completely random characters from all over your keyboard. However, most people can't reasonably memorize such a password.
So what most people do is try to come up with something that's difficult to "read" but follows an easy-to-remember pattern. As Randall correctly points out, this is a losing game, and often results in passwords which are relatively easy to guess using simple attacks.
However, his approach is to choose your password from a list of about 17,592,186,044,416 possible passwords made up of four English words. That's a pretty strong password compared to a lot of the kinds of passwords people typically use, but if you're comparing it to the gold standard (randomly selected characters from all of the 95 characters you can type on the typical U.S. keyboard), then you would only need about a 7 character password to make up the same number of possible passwords. 7 character passwords became relatively trivial to crack when I was still new in this industry, and now even 10 character passwords are looking shaky, just in terms of what it takes to crack the perfect password.
So, is Randall right? Well, yes, sort of. However, the best approach would be to combine all of the best strategies for passwords that are easy to remember, not allowing your attacker to know what kinds of passwords to try. Throw in one really odd word to your four. Change up a common saying. Make your password something that's fun to type. Take a simple phrase and censor it out by replacing a word to two with asterisks in a way that makes it sound funny. Combine the first name of a character with part of a quote they're famous for. Draw some ASCII art.
All of these are individually fairly weak strategies, but when you're creative about every password, it's nearly impossible to use any one scheme's weaknesses against you. If you are a target, specifically, this is a strong defense. If a large number of users are being targeted, then there's a larger problem you have to solve, and more attention to detail may be required to solve the problem.
Here are some examples of pass-phrases that you might use. Think of your own clever ways to twist up the keys on your keyboard and be unpredictable. There are still many useful ways to attack your passwords, but it's going to be much harder than if you choose a simple four-common-word password.
I understand where he's coming from, and he's right on some level, but let me explain to you what the layman heard:
If your password is a space-separated list of four English words, no one will ever be able to crack it!
Sadly, there's even solid proof that that's the case. Here's the first example I've seen of a "password" generator based on his approach: XKCD Password Generator.
All I can say is /facepalm.
OK, so those of you who might not get what's going on, here, this is what he's saying:
When you try to make a very strong password, your first inclination is often to try to maximize the complexity of the password from a human perspective. This works very well if you're willing to memorize, say, 13 completely random characters from all over your keyboard. However, most people can't reasonably memorize such a password.
So what most people do is try to come up with something that's difficult to "read" but follows an easy-to-remember pattern. As Randall correctly points out, this is a losing game, and often results in passwords which are relatively easy to guess using simple attacks.
However, his approach is to choose your password from a list of about 17,592,186,044,416 possible passwords made up of four English words. That's a pretty strong password compared to a lot of the kinds of passwords people typically use, but if you're comparing it to the gold standard (randomly selected characters from all of the 95 characters you can type on the typical U.S. keyboard), then you would only need about a 7 character password to make up the same number of possible passwords. 7 character passwords became relatively trivial to crack when I was still new in this industry, and now even 10 character passwords are looking shaky, just in terms of what it takes to crack the perfect password.
So, is Randall right? Well, yes, sort of. However, the best approach would be to combine all of the best strategies for passwords that are easy to remember, not allowing your attacker to know what kinds of passwords to try. Throw in one really odd word to your four. Change up a common saying. Make your password something that's fun to type. Take a simple phrase and censor it out by replacing a word to two with asterisks in a way that makes it sound funny. Combine the first name of a character with part of a quote they're famous for. Draw some ASCII art.
All of these are individually fairly weak strategies, but when you're creative about every password, it's nearly impossible to use any one scheme's weaknesses against you. If you are a target, specifically, this is a strong defense. If a large number of users are being targeted, then there's a larger problem you have to solve, and more attention to detail may be required to solve the problem.
Here are some examples of pass-phrases that you might use. Think of your own clever ways to twist up the keys on your keyboard and be unpredictable. There are still many useful ways to attack your passwords, but it's going to be much harder than if you choose a simple four-common-word password.
- "David had a little ham..."
- "d00dz, it's full of stars!"
- "CaPsLoCkWoNtHeLpYoU"
- "10qpalzm -- qwerty"
- "dayO dayayayO, dayl1te come"
- "<-- I'm with them -->"
- "Are doomed to repeat it who fail to learn from history those"
- "[(@)(@)(@)(@)(@)(@)(@)]"
- "I'm mad as **** and I'm not going to **** it any more!"
- "Q-36 Explosive Space Modulator Marvin"
- "Just one uncommon lexeme"
- "!!1 thousand X yes!!"
- "._-*-_.o0O*!"
- "Star Wars of the Roses vs. Kramer"
- "Sufficiently large values of +/-n"
- ">->O XKCD O<-<"
Thursday, June 10, 2010
Are your passwords safe in MD5 or SHA-1 formats?
I've read, over and over again, various questions and seemingly authoritative statements about the security of various hashing algorithms. I've gotten kind of tired of reading misinformation, so here's some detail that you can trust.
OK, so what does any of this mean to you? Is MD5 secure? Well, not really. It is possible, with moderate hardware investment and access to the hashed password to generate a "skeleton key." No one can "crack" the original password in a reasonable amount of time that I know of or that I've read about, but access to an equivalent password solves many problems for an attacker, even if they can't then take that password and use it against other services (since those services would not be using the same "salt" which prevents the same password hashing the same way on two different sites or services).
The question you have to ask yourself is this: why are you hashing passwords? Is it to protect them, should someone gain access to your systems from the outside? Is it to protect them from those who have access to the data store? In these cases, md5 is at best a weak protection, but it is significantly better than some of the alternatives (DES, etc.) which are breakable in practically no time.
But MD5 is used in many places besides password hashing. Should we stop using it there? Probably not.
For example many backup and data validation tools use MD5 to make sure that data has not been modified (either to initiate a backup/copy or to safeguard against accidental local change). These purposes are still served just as well now as they were when MD5 was introduced, and the fact that MD5 has been proven to have possible collision attacks does not really impact the data integrity aspect of the algorithm. Of course, there are cases where MD5 will identify a block as unchanged when it has, in fact, changed. This is true for all hashing algorithms, but the reason that MD5 was initially considered acceptable for this purpose was that the chance of that happening without malicious intent is astronomically small (that malicious intent was not believed to be as much of a factor then is not interesting to us, now). It would be a bit like dropping a penny down into one of those boxes with water where the goal is to land it on a small platform, and just as you dropped it, an earthquake struck, causing the penny to bounce off the platform, jump back up through the slot and blind you. Just as I don't recommend avoiding such games because of the risk of blindness, I don't think you need to stay away from hashing algorithms (including MD5) in order to avoid missing a data update. If you think someone might be waiting for you to drop the penny so they can set off some dynamite, then you have a different kind of problem, and MD5 might not be the best choice (e.g. if you're performing MD5 checksums in order to verify that a system's software has not been compromised).
Now, that changes as your risk profile changes. There are times, I believe, where it makes sense to take extra precautions. For example, if you're making constant backups of large amounts of rapidly changing data whose integrity in original and backup form has a high risk associated (e.g. medical data), then I might use two hashing algorithms to perform the verification. MD5 might be a fine choice for one of them, but I'd use SHA-1 or something similar on top of it. It's still astoundingly unlikely to be an issue, but there's a time an place for being stupidly extra-certain and if you can afford the extra CPU cycles, why not compute two hashes while you're looking at the data?
What about SHA-1? Hasn't that been broken too? No, SHA-1 has known weaknesses which will likely yield security-impacting attacks in the future, but as of now, these weaknesses have yet to be translated into actual attack vectors. It's certainly worth staying on top of, and keeping a flexible hashing scheme (ala the OpenBSD/LDAP schema) in your application in order to upgrade to SHA-3 when it becomes available and has been thoroughly tested, but for now SHA-1 is an excellent choice for anything short of military/state-secret sorts of crypto-hashing needs.
Bruce Schneier, who is recognized around the world as an authority on cryptographic security, had this to say about the news regarding SHA-1:
- US-CERT of the U. S. Department of Homeland Security said MD5 "should be considered cryptographically broken and unsuitable for further use."
- The document that this was stated in is titled, "Vulnerability Note VU#836068: MD5 vulnerable to collision attacks"
- A collision attack is where an attacker, given access to a hashed password (or other plain text), crafts a password that yields the same result when hashed. Thus to a password authentication system, the crafted "collision" seems to be the correct password.
- If your password hashing scheme does not use a salt, none of this is interesting to you, as you have little or no security to speak of given an attacker (internal or external) who has access to your hashed passwords.
OK, so what does any of this mean to you? Is MD5 secure? Well, not really. It is possible, with moderate hardware investment and access to the hashed password to generate a "skeleton key." No one can "crack" the original password in a reasonable amount of time that I know of or that I've read about, but access to an equivalent password solves many problems for an attacker, even if they can't then take that password and use it against other services (since those services would not be using the same "salt" which prevents the same password hashing the same way on two different sites or services).
The question you have to ask yourself is this: why are you hashing passwords? Is it to protect them, should someone gain access to your systems from the outside? Is it to protect them from those who have access to the data store? In these cases, md5 is at best a weak protection, but it is significantly better than some of the alternatives (DES, etc.) which are breakable in practically no time.
But MD5 is used in many places besides password hashing. Should we stop using it there? Probably not.
For example many backup and data validation tools use MD5 to make sure that data has not been modified (either to initiate a backup/copy or to safeguard against accidental local change). These purposes are still served just as well now as they were when MD5 was introduced, and the fact that MD5 has been proven to have possible collision attacks does not really impact the data integrity aspect of the algorithm. Of course, there are cases where MD5 will identify a block as unchanged when it has, in fact, changed. This is true for all hashing algorithms, but the reason that MD5 was initially considered acceptable for this purpose was that the chance of that happening without malicious intent is astronomically small (that malicious intent was not believed to be as much of a factor then is not interesting to us, now). It would be a bit like dropping a penny down into one of those boxes with water where the goal is to land it on a small platform, and just as you dropped it, an earthquake struck, causing the penny to bounce off the platform, jump back up through the slot and blind you. Just as I don't recommend avoiding such games because of the risk of blindness, I don't think you need to stay away from hashing algorithms (including MD5) in order to avoid missing a data update. If you think someone might be waiting for you to drop the penny so they can set off some dynamite, then you have a different kind of problem, and MD5 might not be the best choice (e.g. if you're performing MD5 checksums in order to verify that a system's software has not been compromised).
Now, that changes as your risk profile changes. There are times, I believe, where it makes sense to take extra precautions. For example, if you're making constant backups of large amounts of rapidly changing data whose integrity in original and backup form has a high risk associated (e.g. medical data), then I might use two hashing algorithms to perform the verification. MD5 might be a fine choice for one of them, but I'd use SHA-1 or something similar on top of it. It's still astoundingly unlikely to be an issue, but there's a time an place for being stupidly extra-certain and if you can afford the extra CPU cycles, why not compute two hashes while you're looking at the data?
What about SHA-1? Hasn't that been broken too? No, SHA-1 has known weaknesses which will likely yield security-impacting attacks in the future, but as of now, these weaknesses have yet to be translated into actual attack vectors. It's certainly worth staying on top of, and keeping a flexible hashing scheme (ala the OpenBSD/LDAP schema) in your application in order to upgrade to SHA-3 when it becomes available and has been thoroughly tested, but for now SHA-1 is an excellent choice for anything short of military/state-secret sorts of crypto-hashing needs.
Bruce Schneier, who is recognized around the world as an authority on cryptographic security, had this to say about the news regarding SHA-1:
They can find collisions in SHA-1 in 269 calculations, about 2,000 times faster than brute force. Right now, that is just on the far edge of feasibility with current technology.
Jon Callas, PGP's CTO, put it best: "It's time to walk, but not run, to the fire exits. You don't see smoke, but the fire alarms have gone off." That's basically what I said last August.
It's time for us all to migrate away from SHA-1.Hash functions are the least-well-understood cryptographic primitive, and hashing techniques are much less developed than encryption techniques. Regularly there are surprising cryptographic results in hashing ... we still have a lot to learn about hashing.
Most of the hash functions we have, and all the ones in widespread use, are based on the general principles of MD4. Clearly we've learned a lot about hash functions in the past decade, and I think we can start applying that knowledge to create something even more secure.
Tuesday, April 6, 2010
Enforced bad passwords
Long ago, I got sick of sites that restrict me to bad passwords, but today I came across another and it has pushed me to yet again explain why it is that you should never restrict passwords without deeply compelling cause.
Today's offender was Boston Coach, the luxury livery service in that was founded by Boston's Fidelity Investments (the legend states that one day, Fidelity's owner, Ned Johnson wanted a cab and couldn't get one; the next day he had his own fleet of black sedans with smartly dressed drivers, trained to treat their passengers like royalty). Anyway, so I wanted to hire a Coach to take my mother and I to a concert for her birthday (I won't say what birthday; you're welcome, Mom). I had to sign up for an account on their Web site. They committed a few sins in the process:
K1/}"jUCF/byp6( : $1$0ZV5xOu3$iTgccli1bBSykSJxcOrfi.
Notice that this password would be nearly impossible to memorize, but because PasswordSafe stores it in an encrypted file, I just have to remember one, easier to remember password to access all of them. I tried to enter this very password for my account, but don't bother trying to use it... it was rejected. The confusing bit was that the UI informed me that I had not met "minimum password requirements." Wow, if that password doesn't measure up to Boston Coach's minimum requirements, they must spend all day, every day servicing lost password requests!
In reality, what they'd done is refused to accept any password with punctuation (resulting in 31 possible characters being removed from all possible passwords on a typical US keyboard). This is a tragic thing to do to your password security, and a company founded by Fidelity Investments should know better.
Anyway, they should fix their broken software and anyone else that uses such terrible requirements for passwords should get on it ASAP.
Today's offender was Boston Coach, the luxury livery service in that was founded by Boston's Fidelity Investments (the legend states that one day, Fidelity's owner, Ned Johnson wanted a cab and couldn't get one; the next day he had his own fleet of black sedans with smartly dressed drivers, trained to treat their passengers like royalty). Anyway, so I wanted to hire a Coach to take my mother and I to a concert for her birthday (I won't say what birthday; you're welcome, Mom). I had to sign up for an account on their Web site. They committed a few sins in the process:
- Unless you really need a pseudonym, don't ask the user to create one. Instead, use the email address for logins.
- Never restrict passwords unless you are technologically constrained to do so, and if you are, file a security bug with whatever braindead software it was that forced you to (or consider just dumping it).
- Test your UI with and without JavaScript support. This sounds silly, but there are plenty of environments where people aren't allowed to enable unsafe browser features.
- Never give the user an error without explaining what it is that they did to get it. Two examples came up, here: the password security policy and the number of occupants per car.
K1/}"jUCF/byp6( : $1$0ZV5xOu3$iTgccli1bBSykSJxcOrfi.
Notice that this password would be nearly impossible to memorize, but because PasswordSafe stores it in an encrypted file, I just have to remember one, easier to remember password to access all of them. I tried to enter this very password for my account, but don't bother trying to use it... it was rejected. The confusing bit was that the UI informed me that I had not met "minimum password requirements." Wow, if that password doesn't measure up to Boston Coach's minimum requirements, they must spend all day, every day servicing lost password requests!
In reality, what they'd done is refused to accept any password with punctuation (resulting in 31 possible characters being removed from all possible passwords on a typical US keyboard). This is a tragic thing to do to your password security, and a company founded by Fidelity Investments should know better.
Anyway, they should fix their broken software and anyone else that uses such terrible requirements for passwords should get on it ASAP.
Friday, March 26, 2010
Safe browsing and virus removal
Sometimes you have to use Windows. There might be a game you like that only runs there or you might need a Windows-only program for work. Whatever it is that draws you to Windows, you know going in that you run the risk of your system becoming compromised (becoming a "zombie," getting a key-logger or any number of other harmful scenarios). OS/X is starting to feel the heat of increased market share as well, in case Mac fans thought they were somehow immune. In 2009 and now in 2010, Mac/OS + Safari did quite poorly in a challenge to compromise browsers. My brother just recently got some sort of malware that caused him to spam the family with bogus links, and I put together this overview of what to do in response. In case it's useful to others, here you go:
Preventative:
1) Always use Firefox to browse the web (Safari and Chrome are getting there, but currently don't have the suite of helpful and stable plugins that Firefox does) http://www.mozilla.com/en-US/
2) Always use the noscript plugin for Firefox http://noscript.net/ and add exceptions with care
3) If you're going to visit a site that might be questionable, use the "Tools -> Start Private Browsing" feature
Doing anything less is roughly equivalent to going on a sex tour of the third world without condoms. That's not a pretty metaphor, but neither is having your system infected with every bot this side of Robbie from Forbidden Planet.
As for cleaning your existing system... it's hard. The best and safest way is to back up your data and then use the re-install/recovery disks that came with the computer. If you want a less drastic approach (that isn't as guaranteed to work), then I suggest one of these resources:
AntiVir removal tool -- Avira, makers of my favorite free antivirus tool
McAfee Virus Removal Tools -- McAfee (about $90)
Symantec Removal Tools -- Symantec removal tools (free?)
I suggest figuring out what you have first. AntiVir, McAfee or Symantec can be used to do a full scan, and should turn this up. If not, try a malware removal tool like Spybot Search and Destroy SpyBot Search and Destroy (but be careful if you do a Web search for it... don't click on ads, and make sure you spelled it correctly).
To keep yourself safe in the future, make sure you have an up-to-date virus scanning tool (AntiVir has a free version that pops up a single ad for their product only, per day, asking you to buy the full version and there are paid programs from Symantec and McAfee). Also, make sure that you run the latest version of your browser (Firefox will auto-update with security fixes, but you should upgrade to the latest major version at least once every 6 months). Don't use IE. but if you really must, make sure it's updated to the very latest version. Microsoft's track record for keeping old browsers secure isn't very good.
Beyond that, consider doing everything that isn't Windows-specific in a virtual machine. You can get an easy-to-use virtual machine manager at http://www.virtualbox.org/wiki/Downloads and then download the install image for Ubuntu Linux and load it up in the virtual machine. This allows you to do things that would otherwise be unsafe in Windows within a safer environment. It's cumbersome, but the security return on your investment is well worth it.
Preventative:
1) Always use Firefox to browse the web (Safari and Chrome are getting there, but currently don't have the suite of helpful and stable plugins that Firefox does) http://www.mozilla.com/en-US/
2) Always use the noscript plugin for Firefox http://noscript.net/ and add exceptions with care
3) If you're going to visit a site that might be questionable, use the "Tools -> Start Private Browsing" feature
Doing anything less is roughly equivalent to going on a sex tour of the third world without condoms. That's not a pretty metaphor, but neither is having your system infected with every bot this side of Robbie from Forbidden Planet.
As for cleaning your existing system... it's hard. The best and safest way is to back up your data and then use the re-install/recovery disks that came with the computer. If you want a less drastic approach (that isn't as guaranteed to work), then I suggest one of these resources:
AntiVir removal tool -- Avira, makers of my favorite free antivirus tool
McAfee Virus Removal Tools -- McAfee (about $90)
Symantec Removal Tools -- Symantec removal tools (free?)
I suggest figuring out what you have first. AntiVir, McAfee or Symantec can be used to do a full scan, and should turn this up. If not, try a malware removal tool like Spybot Search and Destroy SpyBot Search and Destroy (but be careful if you do a Web search for it... don't click on ads, and make sure you spelled it correctly).
To keep yourself safe in the future, make sure you have an up-to-date virus scanning tool (AntiVir has a free version that pops up a single ad for their product only, per day, asking you to buy the full version and there are paid programs from Symantec and McAfee). Also, make sure that you run the latest version of your browser (Firefox will auto-update with security fixes, but you should upgrade to the latest major version at least once every 6 months). Don't use IE. but if you really must, make sure it's updated to the very latest version. Microsoft's track record for keeping old browsers secure isn't very good.
Beyond that, consider doing everything that isn't Windows-specific in a virtual machine. You can get an easy-to-use virtual machine manager at http://www.virtualbox.org/wiki/Downloads and then download the install image for Ubuntu Linux and load it up in the virtual machine. This allows you to do things that would otherwise be unsafe in Windows within a safer environment. It's cumbersome, but the security return on your investment is well worth it.
Friday, January 8, 2010
An Open Letter to Blizzard: Add a Battle.net Authenticator Option
Recently WoW.com has been suggesting that Blizzard might be on the edge of making these mandatory for the game. I understand this move, but there are two primary reasons people don't agree with it, and that it may well hurt WoW. First I'll cover those reasons and then I'll discuss the ways to work around them without giving up on account security.
(more...)
Subscribe to:
Posts (Atom)