First, I would like to note that this post diverges from my original goals for this blog, but this is unfortunately an item that is necessary to explore, discuss, and understand. I am not a lawyer, do not have legal training, and am giving my thoughts and opinions regarding US law on these matters. This post entirely stems from https://twitter.com/jspilman/status/278284483990519808 and the linked article.
It is clear that reality and the law do not keep pace. I am going to cover the items listed in the article as part of the indictment against Brown. Please note that I am reading and referencing the linked indictment, but this is a scribd.com link and I have not verified the validity or accuracy of it. In any case my intent is not to make direct comments on this case but to use this as sufficient material to discuss how US law applies.
The first important aspect is one of jurisdiction. The indictment starts by establishing the jurisdiction on the basis of interstate commerce. Discard all common sense when it comes to US law and interstate commerce. There is case law for which the possibility of interstate commerce was sufficient to invoke federal jurisdiction, without the requirement that any intent or interstate commerce was shown. Right or wrong, this barrier to start a case has such a low bar that it is nothing but a formality.
For the first count, it is unclear if his offense is literally copying an url from one IRC channel to another. We could theorize that the defendant downloaded it, torrented it, and so on, but for the law simply passing the url around fits the requirement of making it available. The law makes no remarks here on if the defendant had a copy, sent copies, etc.
The second count addresses "intent to defraud" and intent is almost as laughable as establishing jurisdiction today. In some laws establishing intent is a high and difficult bar to establish, but in cases of unauthorized access devices the possession itself establishes intent to defraud based on current case law. Yes, this means that possession and intent are synonymous in this case.
Counts two through twelve simply allege the defendant "knowingly transferred and possessed without lawful authority..." some specific data. Here the standard of intent is even more of an afterthought. If the prosecution can prove that the defendant possessed the data, then this is essentially game over. The defense would have to prove the defendant did not have the data, or did not know he had it, or did not know it was unlawfully obtained, etc.
My primary intent in this post is to put everyone in a guarded and vigilant position when it comes to data leaks and US law. Most of these laws have no affirmative defense at all and ignorance is certainly not part of them. Jurisdiction and intent are quaint ideas that are codified but irrelevant to successful defense efforts.
Jeremy Spilman's original question/alluded question is whether or not these laws or similar laws can be used to go after people who have password lists. The answer is absolutely yes. Therefore, when it comes to free speech and research in the US, you had better be a full time university student or professor or you should expect zero legal protection. The discussion of the first amendment, free speech, and research is well out of the scope of this post.
What practical advice should you take from this? It is not a question of if password lists are next but when the indictments start, assuming they have not already.
2011-10-28
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.
2011-06-14
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.
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.
2011-06-13
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.
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.
Subscribe to:
Posts (Atom)