Weekly Edition
Return to the Security page
| |||||||||||||
Security quotes of the week
This led us to ask, if in the worst case users chose multi-word passphrases
with a distribution identical to English speech, how secure would this be?
Using the large Google n-gram corpus we can answer this question for
phrases of up to 5 words. The results are discouraging: by our metrics,
even 5-word phrases would be highly insecure against offline attacks, with
fewer than 30 bits of work compromising over half of users. The returns
appear to rapidly diminish as more words are required. This has potentially
serious implications for applications like PGP private keys, which are
often encrypted using a passphrase.
-- Joseph Bonneau
Within 48 hours of the system going live, we had gained near-complete control of the election server. We successfully changed every vote
and revealed almost every secret ballot. Election officials did not detect
our intrusion for nearly two business days — and might have remained
unaware for far longer had we not deliberately left a prominent clue.
-- Scott
Wolchok, Eric Wustrow, Dawn Isabel, and J. Alex Halderman in Attacking the Washington, D.C.
Internet Voting System [PDF](Log in to post comments)
Security quotes of the week Posted Mar 16, 2012 11:57 UTC (Fri) by jschrod (subscriber, #1646) [Link] Even better, in Halderman et.al.'s paper:The first SSH attack we observed came from an IP address located in Iran (80.191.180.102), belonging to Persian Gulf University. We realized that one of the default logins to the terminal server (user: admin, password: admin) would likely be guessed by the attacker in a short period of time, and therefore decided to protect the device from further compromise that might interfere with the voting system test. We used iptables to block the offending IP addresses and changed the admin password to something much more difficult to guess. We later blocked similar attacks from IP addresses in New Jersey, India, and China.»This is our security test, US persons only. Stay away!«
DC Internet voting test Posted Mar 17, 2012 19:44 UTC (Sat) by giraffedata (subscriber, #1954) [Link] »This is our security test, US persons only. Stay away!« I didn't see anything like that. 3 of the 4 hackers, who were plain old Internet password guessers, the researchers noticed were from other than the US, but they blocked every one they saw because they wanted to preserve as much of the test as possible. Note that the researchers themselves were careful not to disturb the system more than they had to.
DC Internet voting test Posted Mar 17, 2012 19:51 UTC (Sat) by giraffedata (subscriber, #1954) [Link] A particularly interesting fact about this hack, for this audience, is that it was made possible by open source. The researchers read source code and found a carelessly coded Bash program that used a user-supplied string inside double quotes. (So they made that string $(my-command) and that was that). They say that without source code the system still could have been compromised, but with more work. But they don't elaborate and I wasn't convinced.
DC Internet voting test Posted Mar 18, 2012 0:21 UTC (Sun) by nybble41 (subscriber, #55106) [Link]
To clarify a couple of points:
1) This appears to have been a Ruby program, not a Bash program. Bash was only involved because it was running an external program (gpg) using the common "/bin/sh -c shell-command" idiom, and Bash was probably providing /bin/sh via a symlink. Bash will not execute commands inside variables expanded inside double-quotes. E.g. if CMD='$(my-command)' then "$CMD" evaluates to the literal string "$(my-command)" rather than executing my-command. Ergo, if the program had been written in Bash it would probably not have this particular vulnerability.
3) The Ruby program constructed its shell command by simply pasting the user-provided string inside double-quotes, without quoting the string itself. This is a classic injection vulnerability in *any* language--all you have to do to run arbitrary commands is include the closing quote in the user-provided string. SQL is particularly well-known for this. Since they were also using double-quotes, rather than single-quotes, any metacharacters in the string (variable expansion, command expansion) will be processed by the shell as part of the command.
The whole problem could have been bypassed by using something like Perl's quotemeta function instead of double-quotes, or by using the built-in Ruby support for executing programs with an array of arguments without involving the shell.
4) Even without access to the (Ruby) source code, any process on the same system could see that it runs this shell command by watching the output of ps(1) or /proc/*/cmdline. From there it's not a very far jump to checking the arguments for shell code injection vulnerabilities.
DC Internet voting test Posted Mar 18, 2012 0:38 UTC (Sun) by giraffedata (subscriber, #1954) [Link] 4) Even without access to the (Ruby) source code, any process on the same system could see that it runs this shell command by watching the output of ps(1) or /proc/*/cmdline. From there it's not a very far jump to checking the arguments for shell code injection vulnerabilities. It's worth noting that that wouldn't have helped in this case, since the researchers did not have access to /proc/*/cmdline (via 'ps' or anything else) until they read that source code. It's a common security measure not to openly provide facilities for looking at arbitrary files or running arbitrary programs on the system -- a measure that seems to have been implemented in the DC voting system.
DC Internet voting test Posted Mar 18, 2012 9:24 UTC (Sun) by khim (subscriber, #9252) [Link] They say that without source code the system still could have been compromised, but with more work. But they don't elaborate and I wasn't convinced. No? Why no? Demostration without published sources http://lwn.net/Articles/485162/ happened just a couple of weeks ago. Sure, if they will build everything from scratch without using any COTS components then yes, it'll be much harder - but a few orders of magnitude more expensive, too.
DC Internet voting test Posted Mar 19, 2012 18:50 UTC (Mon) by raven667 (subscriber, #5198) [Link]
I would also point out that SQL injection is the same kind of vulnerability, passing unsanitized data to an interpreter, and is most often found without any access to source code in web apps. Reading the source code to find the vuln may have been convenient for them but certainly wasn't required and isn't even the most convenient for everyone. Some people prefer writing a test suite to poke for vulns rather than trying to audit all the source.
Security quotes of the week Posted Mar 19, 2012 14:12 UTC (Mon) by ekj (guest, #1524) [Link]
The net is littered with articles that claim that if you pick a word from a vocabulary of 15000 words, then this gives 15 bits of entropy, and 5 words thus gives 75 bits. Such as this one: https://xkcd.com/936/ for example.
The part that is essntial, yet overlooked is that that is only true if the words are picked *randomly* and if people pick words themselves, they'll be anything but.
People *will* choose common words -much- more often than rare words, and the resulting entropy will suffer. Furthermore it's quite likely people will choose *related* words, which lowers the useful entropy even further. What's the real strength of: "horse saddle barn apple" ? Certainly not 60 bit.
The worst case isn't users selecting words according to english distribution. The worst-case is worse: The worst-case is that they select words according to english frequency, and additionally according to english neighbour-frequency. "saddle" is much more frequently the neighbour of "horse", than of "paracetamol".
Security quotes of the week Posted Mar 19, 2012 15:59 UTC (Mon) by anselm (subscriber, #2796) [Link] A 10-line script that randomly picks a number of words from /usr/share/dict/words should take care of that problem. I just wrote one. It took five minutes.
Security quotes of the week Posted Mar 19, 2012 21:16 UTC (Mon) by jimparis (subscriber, #38647) [Link] Or just:egrep '^[a-z]+$' /usr/share/dict/words | sort -R | head -5
Security quotes of the week Posted Mar 19, 2012 21:46 UTC (Mon) by neilbrown (subscriber, #359) [Link]
Brilliant:
schmeared
and so easy to remember too.
My first thought was that this would be a great way to extend your vocabulary. But then I realised you would be afraid to ever *use* these words in case someone guessed.
The hierogrammatist craved the repercussing effects of schmeared ethnocides.
Unfortunately most of by banks limit passwords to 6 or 8 chars, otherwise I would so be using that.
Security quotes of the week Posted Mar 19, 2012 22:04 UTC (Mon) by jimparis (subscriber, #38647) [Link] You could limit it to short words and still get quite a bit of entropy:
$ egrep '^[a-z]{3,6}$' /usr/share/dict/words | sort -R | wc -l
14706
$ egrep '^[a-z]{3,6}$' /usr/share/dict/words | sort -R | head -5
sinker
bogey
grim
rhythm
choked
log(14706) / log(2) * 5 = 69 bits. But still too long for a bank or many other password forms, as you mentioned.
Security quotes of the week Posted Mar 19, 2012 22:21 UTC (Mon) by anselm (subscriber, #2796) [Link] That's why my script is 10 lines. You don't want to take just any word from the dictionary :^)
Security quotes of the week Posted Mar 20, 2012 2:12 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
>septums
>bumping >Hasidim >thermoplastics >stonework
I like it! That's going to be my password for GMail account. Oh wait...
Security quotes of the week Posted Mar 26, 2012 7:40 UTC (Mon) by robbe (guest, #16131) [Link]
> Unfortunately most of by banks limit passwords to 6 or 8 chars, otherwise I
> would so be using that. Rather than cynicism, it would be nice to know how many bits you need. For banking, let's just hope offline attacks are not possible. Otherwise, you are dead in the water, unless you use 8 characters *including* some very hard to input ones (i.e. outside 0x20-0x7F).
Even 64 would not be that great for an offline attack, but that is highly dependent on the crypto used. If we assume 64 bit as sufficient, then 6 words from http://ogden.basic-english.org/word2000.html will be enough. Should be doable.
Alternatively, take fewer words from a bigger dictionary. You didn't mention the size of yours, I'll assume 300000 words, as that's more or less what I have (wbritish-huge from Debian). Three words fall short (55 bits), and four are way better (72 bits). I guess the Ogden option is preferable.
Online attacks are, in theory, easy to detect and control. Four words from Basic English are more than enough to deflect these. Hell, even a single dictionary word probably is, if you take care to exclude the top 100 passwords.
Security quotes of the week Posted Mar 26, 2012 11:46 UTC (Mon) by ekj (guest, #1524) [Link]
Banking should be two-factor anyway, which greatly reduces the needed keyspace. You can, afterall, withdraw money from an ATM with a 4-digit PIN, which means there's only ~10 bits of protection in that one factor.
But that's still adequate because you need physical posession additionally, and because the ATM will eat the card after 3 failed attempts at guessing the PIN. Stealing a card isn't very much worth it if that gives you 3/10000 chance of getting at the money.
My online bank uses a password, and a 6-char tan that's sent as an SMS to my mobile phone. Neither of these are secure by itself, but the *combination* helps a lot. You'd need to steal my phone (or somehow snoop on my SMS) -and- learn or guess my password. Doing both is a lot harder than doing one.
Security quotes of the week Posted Mar 27, 2012 11:11 UTC (Tue) by etienne (subscriber, #25256) [Link]
> My online bank uses a password, and a 6-char tan that's sent as an SMS to my mobile phone. Neither of these are secure by itself, but the *combination* helps a lot.
Do not protect you against MITM, and it seems massive scale MITM are hapenning right now.
Security quotes of the week Posted Mar 27, 2012 11:51 UTC (Tue) by ekj (guest, #1524) [Link]
It does actually, because the SMS includes payment info:
"Use the TAN 45FEA0 to authorise payment of $225.50 to [recipient]".
Thus if someone had a MITM-attack going on my computer, they'd still need to be able to MITM the SMS-channel too, which *does* significantly raise the bar.
Security quotes of the week Posted Mar 27, 2012 11:56 UTC (Tue) by ekj (guest, #1524) [Link]
And "tan" stands for "transaction authorisation number" so obviously there's one for every transaction. Though for convenience there's a setting to disable it for payment that are a) to a recipient that's received payments from me already in the last year and b) under a specific sum.
Thus I can say "don't require a TAN if sending money to someone I've sent money to before, and the amount is less than $1000".
But if I'm paranoid, I don't need to set that, in which case a TAN is used for every transaction.
Security quotes of the week Posted Mar 20, 2012 12:16 UTC (Tue) by ekj (guest, #1524) [Link]
Then you get passwords like:
noncontemptibleness
This is very secure. But it royally sucks to remember, and to type. Both matters. I'd rather memorise, and type, a 8-char randomly-generated password than this thing. (might not be quicker to learn that way, but would be way quicker to use after I learn it)
No matter how you slice it, the set of pass-phrases that are both secure, possible to remember, and reasonably quick to type, shrink every year.
|
|||||||||||||