All your RSA token seeds are safe ;)

As many of you are aware RSA, the company not the public key cipher, had some security issues.  In particular it related to an APT (Advanced Persistent Threat), really it's called a Trojan and they are not new, and compromises of SecureID tokens.  Well, it seems that their initial statements that no token seeds were compromised and all the various PR double-speak were outright lies.  Many are already aware of this fact but I was quite surprised to finally see a response from a company that I have such a token from.

For one of my banks I could purchase a Secure ID token for somewhere between $20 - 30 USD for the device and then pay $5 USD/mth for the privilege of using it.  I should note that this token is actually not capable of being part of my actual bank sign on.  It is only part of vSafe which stores things like all your statement history since you opened your account and any documents up to 1 GB that you wish to put there.  They claim it is encrypted, no details available, but that they will turn over all your data to law enforcement if necessary so likely by encrypted they mean the SSL *to them* and not the actual data.

After the RSA Secure ID breach I started sending emails, calling, and so on to demand they replace my now compromised token.  Most people that I encountered did not even know they offered this and the general response was that it might be more secure to terminate my token and use the SMS 24 hour codes instead.  That's right a code sent to you via SMS that is valid for 24 hours *or* your Secure ID token that changes a bit more regularly than that.  Others helpfully offered to disconnect my token and then charge me $20 - 30 USD to have a new one shipped.  Of course maybe I would just get part of the bad batch again.

Much to my surprise I received a FedEx package with this letter and a new token.  I would like to highlight some things like "ongoing security process."  My old token has an expiration of 2013-12-31 and was issued 2010-05.  My new token has an expiration of 2016-12-31.  Really, their ongoing security process includes issuing new tokens less than 1.5 years later and some 2+ years in advance of the expiration?

I also like the fact that the document ends with SSA_L_AllTokenReplacement which seems like some sort of internal document name.  I wonder why there would be a need for AllTokenReplacement?

For those not yet aware of devices such as the Yubikey then I suggest you look into them.  Between cheaper token costs, ability to use their auth server or with Kerberos run your own, etc. they are much more cost effective than the RSA tokens and all details are publicly available.

GRC haystack 2 - rainbow tables

I did not intend to spend so much time on this topic but @itinsecurity had the time to listen to the 37 minute podcast and the claim is this padding scheme is immune to rainbow tables.  I intentionally did not do rainbow table analysis because I already had a long post.  Also, to even enter this discussion we have to assume the application in question does not store passwords plaintext and instead hashes them.  Additionally, we assume the attacker already has all the hashes.

Lets start with
password: Summer
[A-Za-z][a-z]{5}
52^1 * 26^5 which is roughly 2^29.203

Lets pick some potential padding characters: [., ].  Alright how about the character sets:
[A-Za-z][a-z]{5}[a-z., ][., ]{1,4}
52^1 * 26^5 * 29^1 * 120 which is roughly 2^40.968
length 8 to 11

[A-Za-z][a-z]{5}[a-z., ][., ]{1,8}
52^1 * 26^5 * 29^1 * 9840 which is roughly 2^47.325
length 8 to 15


Perhaps users will cease to append years to the end of the password and add a padding character every password change?  Alright lets go for larger character sets:
[A-Za-z][a-z]{5}[a-z.,<->\*\[\] ][.,<->\*\[\] ]{1,4}
52^1 * 26^5 * 35^1 * 7380 which is roughly 2^47.181
length 8 to 11

Does this mean it is rainbow table proof?  Hardly.  It just means traditional tables may not be useful but plenty of options exist to defeat them: length, unicode, etc.  Sure some users may put padding at the beginning, at the end, make it really long, etc. but this just gets silly.  Using 4 randomly selected words from diceware's list gives you 7776^4 or 2^51.699 and that's purely lower case, no padding, no symbols, etc.  Average length of a word is 4.2 characters.

GRC haystack

@thorsheim has been pestering me to start a blog and I have given in since twitter is a bit limiting.

The GRC haystack is the subject of this post.  Both @itinsecurity and @thorsheim asked for my remarks.

Directly speaking entropy for passwords is quite important.  However, there are a lot of variations on how to construct a good password.  Keyspace in some cases, as Steve Gibson claims in this specific case, may actually be more important.  The argument on its face is designed to be counter-intuitive in order to convince you to buy into his insight.

Entropy in a password is hard to estimate unless the password is truely randomly generated.  Keyspace is much easier to measure.  However, Gibson's claim relies on several premises:
1) the user constructs a padding system that increases length and thus keyspace
2) the padding scheme remains unknown to an attacker
3) the attacker therefore can only attempt a dumb bruteforce attack

Premise 1 relies on the user to construct some padding system that is to remain secret, thwart the attacker, and its re-use is encouraged.  The fact that many applications still store plaintext passwords means that re-use of the padding scheme is an extremely bad idea.

Given what we already know about user behavior is that any ending characters or "padding characters" will likely be of low entropy.  I would assume that users would be likely to pick a single character for padding and use it.  This would render the scheme effective against current rainbow tables but useless against any per position brute forcers designed for exactly this sort of attempts to foil the attack.  Additionally, users really dislike additional keystrokes such as shift so they aren't going to go for complex patterns of padding characters.  At most this scheme means you might stay ahead of brute forcers and rainbow tables until the scheme enters common use and becomes known due to yet another application leaking plaintext passwords.  Also, it will encourage users to create shorter length high entropy passwords because the padding characters will "save them."

I've already touched on premise 2 a bit but it bears repeating that this scheme only works if it can't be guessed, realized, disclosed, etc. to an attacker.  Try convincing a user to type several iterations of <;> at the end of a password and they will just use a lot of 0s or anything that requires no shift.  Oh, and the user needs to remember how many of these padding sequences they use and repeat them later.

Premise 3 completely falls apart given either premise 1 or premise 2 falling apart.

Now, lets discuss counter-intuitive schemes like passphrase construction that don't actually use low entropy to increase keyspace.  Systems such as diceware passphrase creation are a much better idea.  Oh, and don't re-use those passwords since you should assume that at least one application you use is irresponsible in its passowrd storage.

Unfortunately, most users take any security advice they are given and snake oil solutions are embraced without a second thought.  Suggestions such as the GRC haystack are yet another example of bad advice from "security professionals" that likely will be followed by some users.  There are many ways to make better passwords but this scheme is not one of them.