Security quotes of the week
Posted Mar 16, 2012 11:57 UTC (Fri)
by jschrod (subscriber, #1646)
[Link] (1 responses)
Posted Mar 17, 2012 19:44 UTC (Sat)
by giraffedata (guest, #1954)
[Link]
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.
Posted Mar 17, 2012 19:51 UTC (Sat)
by giraffedata (guest, #1954)
[Link] (4 responses)
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.
Posted Mar 18, 2012 0:21 UTC (Sun)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
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.
Posted Mar 18, 2012 0:38 UTC (Sun)
by giraffedata (guest, #1954)
[Link]
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.
Posted Mar 18, 2012 9:24 UTC (Sun)
by khim (subscriber, #9252)
[Link] (1 responses)
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.
Posted Mar 19, 2012 18:50 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
Posted Mar 19, 2012 14:12 UTC (Mon)
by ekj (guest, #1524)
[Link] (12 responses)
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".
Posted Mar 19, 2012 15:59 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (11 responses)
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.
Posted Mar 19, 2012 21:16 UTC (Mon)
by jimparis (guest, #38647)
[Link] (10 responses)
Posted Mar 19, 2012 21:46 UTC (Mon)
by neilbrown (subscriber, #359)
[Link] (8 responses)
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.
Posted Mar 19, 2012 22:04 UTC (Mon)
by jimparis (guest, #38647)
[Link]
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 :^)
Posted Mar 20, 2012 2:12 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I like it! That's going to be my password for GMail account. Oh wait...
Posted Mar 26, 2012 7:40 UTC (Mon)
by robbe (guest, #16131)
[Link] (4 responses)
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.
Posted Mar 26, 2012 11:46 UTC (Mon)
by ekj (guest, #1524)
[Link] (3 responses)
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.
Posted Mar 27, 2012 11:11 UTC (Tue)
by etienne (guest, #25256)
[Link] (2 responses)
Do not protect you against MITM, and it seems massive scale MITM are hapenning right now.
Posted Mar 27, 2012 11:51 UTC (Tue)
by ekj (guest, #1524)
[Link]
"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.
Posted Mar 27, 2012 11:56 UTC (Tue)
by ekj (guest, #1524)
[Link]
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.
Posted Mar 20, 2012 12:16 UTC (Tue)
by ekj (guest, #1524)
[Link]
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.
Even better, in Halderman et.al.'s paper:
Security quotes of the week
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
»This is our security test, US persons only. Stay away!«
DC Internet voting test
DC Internet voting test
DC Internet voting test
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
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
Security quotes of the week
Security quotes of the week
Or just:
Security quotes of the week
egrep '^[a-z]+$' /usr/share/dict/words | sort -R | head -5
Security quotes of the week
repercussing
craved
ethnocides
hierogrammatist
You could limit it to short words and still get quite a bit of entropy:
Security quotes of the week
$ 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
Security quotes of the week
>bumping
>Hasidim
>thermoplastics
>stonework
Security quotes of the week
> 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).
Security quotes of the week
Security quotes of the week
Unless you get a text for each transactions while you are connected to your bank, it is not very safe.
Security quotes of the week
Security quotes of the week
Security quotes of the week
sphaerolite
pseudelephant
dogeship
oxhide