I stumbled across an article on car software viruses. I did not see anything unexpected really. The experts “hope” to get it all fixed before the word gets out and things start getting messy. Which tells us that things are in a pretty bad shape right now. The funny thing is though that the academic group that did the research into vehicle software security was disbanded after working for two years and publishing a couple of damning papers, demonstrating that “the virus can simultaneously shut off the car’s lights, lock its doors, kill the engine and release or slam on the brakes.” An interesting side note is that the car’s system is available to “remotely eavesdrop on conversations inside cars, a technique that could be of use to corporate and government spies.” This goes in stark contrast to what car manufactures are willing to disclose: “I won’t say it’s impossible to hack, but it’s pretty close,” said Toyota spokesman John Hanson. Basically, all you can hope for is that they are “working hard to develop specifications which will reduce that risk in the vehicle area.” I don’t know, mate, I think I better stay with the good old trustworthy mechanic stuff. I guess I know too much about software security for my own good. I kinda feel they will be inevitably hacked. Scared? If there is a manual override for everything – not so much but… The second-hand car market suddenly starts looking very appealing by comparison…
When we invented NFC (Near Field Communication) we never intended it for some of the uses that it was put to afterwards. And when we started discussing those unconventional (for us) uses, we immediately pointed out all security problems and proposed methods to protect the NFC devices from various attacks. That was… probably 2004. Do you think anyone listened? Nope. After that, we put in a few years worth of work into some (ok, granted, fairly fuzzy for political reasons) guidance, standards and white papers in Ecma International and NFC Forum. Did anyone take notice? I don’t think so.
At the recent Black Hat security conference security researcher Charlie Miller detailed and demonstrated attacks to the NFC devices and showed how he can pown a mobile phone through a combination of NFC and browser attacks.
The reason? NFC is a new attack surface and it has to be protected, both by itself and in comnbination with all the other things that are operating in the same device. However, the usual thing has happened. People paid attention only to the hype of usefulness and ease of use of the technology but never paid attention to the security of it. Now the security will have to be added, again, as an afterthought.
Duh, the humanity.
- Researcher wows Black Hat with NFC-based smartphone hacking demo (networkworld.com)
- Hackers May Use NFC Feature to Attack Phones (devicemag.com)
Google has been fined $22.5 million for breaching its privacy commitment and bypassing Apple’s Safari users security settings. As the article in Mercury News comments, citing Consumer Watchdog, “the commission has allowed Google to buy its way out of trouble for an amount that probably is less than the company spends on lunches for its employees and with no admission it did anything wrong.”
The days of when the motto of Google “do no harm” could be taken literally are long gone. Beware.
- Google pays $22.5 mln to settle Apple Safari charges – Reuters (in.reuters.com)
- Google to pay US$22.5 million fine over privacy practices (computerworld.co.nz)
There is a very interesting article in Wired by one of its authors, Mat Honan, about how his digital life was taken over and wiped out completely in the space of one evening. Read How Apple and Amazon Security Flaws Led to My Epic Hacking.
According to an article in Digital Trends, Dropbox leaked an unknown number of passwords. The interesting part here is that they claim an attacker had access to an employee’s account where a list of e-mail addresses was found. Dropbox is not making the news for the first time and this time they promise tougher security measures.
Unfortunately, I do not think tougher security measures they propose would alleviate the problem of employees keeping lists of accounts in their dropboxes.
We discussed the password storage in the article Speaking of passwords…and concluded that password implementation requires a cryptographically strong, contemporary (as in “very, very slow”) one-way hash function with a randomly generated salt for every password.
This is pretty much all you need to take care of. Salting is fairly straight-forward but it is essential to make sure it always works. Achieving a good balance between the slowness of the hashing algorithm for the attacker and an acceptable user performance is just a bit more involved but the things like key stretching techniques have been around for literally ages now too.
It is rumored that Thomas Ptacek once said:
What have we learned? We learned that if it’s 1975, you can set the ARPANet on fire with rainbow table attacks. If it’s 2007, and rainbow table attacks set you on fire, we learned that you should go back to 1975 and wait 30 years before trying to design a password hashing scheme.
We learned that if we had learned anything from this blog post, we should be consulting our friends and neighbors in the security field for help with our password schemes, because nobody is going to find the game-over bugs in our MD5 schemes until after my Mom’s credit card number is being traded out of a curbside stall in Tallinn, Estonia.
We learned that in a password hashing scheme, speed is the enemy. We learned that MD5 was designed for speed. So, we learned that MD5 is the enemy. Also Jeff Atwood and Richard Skrenta.
Finally, we learned that if we want to store passwords securely we have three reasonable options: PHK’s MD5 scheme, Provos-Maziere’s Bcrypt scheme, and SRP. We learned that the correct choice is Bcrypt.
And I think that is a great summary.
TechRepublic has an interesting article “Website and app security tips for software developers” that talks in a very short space about a whole bunch of things, from the “shelf life of software developers” to the advice on security for the website developer.
It provides in particular an interesting insight into why a person thoroughly familiar with security made security mistakes again and again.
I know why I made those mistakes — it was either the hubris of “I can roll my own better than off-the-shelf,” or the idea that slapping something together quickly would be fine “for now” and I would pay the technical debt off later. I was wrong on both counts, every single time.
How often do we get trapped like that?
When working on security, there is something extremely important to keep in mind at all times. We are not trying to make systems impenetrable. We are trying to make it real, real hard for the attacker, that’s all.
If an attacker has physical access to your system, you lost. All measures, passwords, firewalls, everything is there to deter an attacker that is attacking remotely. But the only thing that actually stands between your system and a determined attacker is your door lock. Never thought of that, did you? The security of your computer at home is only as good as your door lock.
Yes, there are smart cards that are physically secure computers. But their application is limited and most if the time we have to deal with systems that we protect in the “virtual world” while in the real world they are basically defenseless. So we make it harder for the attackers with door locks, security guards and CCTV cameras.
Again, we are just making it harder, not impossible. Impossible would be impossible, not to mention prohibitively expensive. Given that an attack is always possible and there are many venues of attack, the attacker will always tend to choose a path that is most economical – the cheapest way to break into your system.
My task as I see it is to convince you to use such security measures that it becomes cheaper for the attacker to break into your house than to attack your computer through the software. Once we are at that point, you start looking into the well-understood world of physical security and my task is done. But we are far from there.
Wouldn’t it be quite logical to talk about passwords after user names? Most certainly. Trouble is, the subject is very, very large. Creating, storing, transmitting, verifying, updating, recovering, wiping… Did I get all of it? It is going to take a while to get through all of that, do you reckon? Let’s split the subject and talk about password storage now, as the subject that comes most often in the security discussions and in the news.
Speaking of which, some recent break-ins if you were not keeping track:
LinkedIn – 6.5 million passwords stolen, Yahoo – 450 thousand passwords stolen, Android Forums – 1 million, Last.fm – 8 million, Nvidia – 400 thousand, eHarmony – 1.5 million, Billabong – 21 thousand, TechRadar … the list is going on and on.
Out of 8 million passwords in LinkedIn and Last.fm breach, “It took a user on the forum less than 2½ hours to crack 1.2 million of the hashed passwords, Ars Technica reported.”
Oops. Is that supposed to be so easy? Actually… no.
There are few easy rules for storing the passwords. First of all, never store passwords in clear, unencrypted, like Billabong did. You remember that any and every system was or will eventually be broken into. You have to assume that your password database will fall into wrong hands sooner or later. Your password database has to be prepared for that eventuality to look good in the eyes of the press.
So, when your password database is in the hands of the attackers, it has to defend itself. A database full of unencrypted passwords does not provide any defense of course. What about an encrypted database?
Well, since you have to be able to use the database, you have to decrypt it when you need it. So the system will have the key to the database somewhere. Since the attacker got hands onto the database, there is no reason why the attacker should not get the encryption keys at the same time. So this is definitely not improving the situation.
Secure hashes (as in the name of this blog) are the ultimate answer. The important thing about the hashes is that they do not require a use of a key and they can be easily computed only one way: from the clear piece of information into the hash. They cannot be reversed, one cannot easily compute the original piece of information from the hash. That’s why they are called one-way hashes.
The hashes were invented a long time ago and they were improving over the years. The old hashes are not secure anymore with the increases in the computing power. That’s what they talked about when they referred to recovering the plain text passwords – they computed passwords that will result in the hash that is in the database.
Finding the passwords then given a database of password hashes boils down to taking a password, computing its hash according to the algorithm used, and comparing it to the hashes stored in the database. When a match is found – we have a good password. This is where the cost of computing the hashes comes in. Older hashes are much faster, newer hashes are much slower. With the advent of rental cloud computing services this is becoming a small distinction though. All SHA-1 passwords of up to 6 characters in length could be brute forced in 49 minutes with the help of Amazon EC2 for a cost of $2 two years ago. And it’s getting cheaper and faster. So here is where the speed matters but it has the opposite effect. The hash, to be secure, must be a very, very slow one. Almost too slow to be useful at all would be a good start.
Even if the computer systems weren’t getting blistering fast compared to the blistering fast of five years ago all the time, a workaround was figured a long time ago. If you are prepared to invest in some large storage, you can compute slowly but surely an enormous amount of hashes and keep them somewhere. When the time comes, you just have to go and compare the hashes you computed in advance to the given hashes in the password database. This is called using rainbow tables. And it’s bloody effective.
Ok, ok, it is not all that gloomy. This fight is an old one and we have defenses. A very effective measure against the rainbow tables is to use a cryptographic salt. A salt is an additional piece of data supplied to the hash function together with the password. Since the attacker did not know the salt in advance, precomputed rainbow tables suddenly become useless. Great. Unfortunately, many sites use a fixed salt that is generated once and set in stone. This effectively makes rainbow tables useful again. One just has to compute them once with that salt again for the whole database. So the salt, to be useful, must be generated new for every password and stored together with the password.
So, finally, the answer is simple: a cryptographically strong, contemporary (as in “very, very slow”) one-way hash function with a randomly generated salt for every password. And anything deviating from that is just plain tomfoolery.
- An Illustrated Guide to Cryptographic Hashes by Steve Friedl
- Holy Hash! Yahoo! keeps passwords in clear! (tigrino.wordpress.com)
- Let’s talk about password storage (mozilla.org)
- 154 Billion Hashes per Second with Multiforcer Password Cracker (cyberarms.wordpress.com)
- How Your Passwords Are Stored on the Internet (and When Your Password Strength Doesn’t Matter) [Explainers] (lifehacker.com)
I think I already talked about this subject previously but not here. Anyhow, the subject bears repeating.
Many go “yippee!” at the mention of biometrics and start to think their user authentication problem is solved. Do not pay attention, they will end up in the newspaper headlines fairly soon, either for massive security failures or being bankrupt, or both.
The problem is not a huge false negative rate, and it is not the huge false positive rate either. The problem is immutability of the characteristics. The biometric characteristics change slowly over time as you age and can be influenced by the environment but they cannot be changed at will (well, at least not easily). The problem is that whatever this thing is, it is a part of your body and is most of the time something you do not want to change even if you had a possibility to do so.
And that’s also why it is dangerous – you may end up losing a limb or two.
The first question that should be asked then, “what’s it good for, anyway?” A characteristic that is fairly stable, cannot easily be changed at will, – that’s a fairly reasonable user name, i.e. the user identification. Even then, it is a questionable approach because it is a good idea to let users change names.
Biometrics is definitely not any good for authentication, that is, proving that you are who you say you are. If you compare to the familiar authentication with passwords, you will notice that the means of authentication are supposedly:
- secret or concealable
- easily changeable in a controlled manner
- transferrable in a controlled manner
And biometrics is none of that.
But why then? Oh, I do not expect to find a definitive answer to that but one thing could be that it looks cool in movies. The other is that biometrics were historically good for tracking people that are not actively resisting such tracking. But then we talk about politics and power and that is not the subject of this discussion at all. One thing is certain: whatever the reason to use biometrics is, it has absolutely nothing to do with security.
So when you see claims like “Biometric is the most secure and convenient authentication tool”, now you know that’s just utter nonsense and you should stay away from people (and companies) making such claims. Unless there isn’t enough nonsense in your life, of course.
When it’s your responsibility to implement a security system, try to stay away from biometrics, you’ll live a happier life. Leave it to Hollywood.