Passwords With a Grain of Salt

90% of time that I see hashed password in database, it is result of MD-5, SHA-1 or similar hash algorithm. While this does satisfy bare minimum requirements for password storage it is not enough.

Problem lies in “rainbow table” attacks. While checking password against all possible combinations seems difficult, it becomes easier once you get one big file with all those combinations pre-computed. Cracking password becomes just searching for already existing hash. Yes, amount of data is quite big (hundreds of gigabytes) but any personal computer can handle this easily.

All you need is to download pre-existing rainbow table and check all entries against your hash. I checked this against some passwords I had access to and success rate was near to 100%. It was very scary experience. Fortunately, there is easy solution - just introduce salt.

Salt consists of few random bytes appended to password (8 bytes seems like nice number). Our hashing function then becomes:

hash = SHA1(password + salt)

This simple step invalidates all precomputed rainbow tables. Even better, since salt differs between users, each user must be attacked separately. Time for cracking just got increased significantly.

Cost on implementation side is just having another field for storing salt. Cost of few additional bytes per user seems reasonable.

Storing Passwords

More often than not I see big errors in how passwords are stored in database. Because of that I decided to make little series about passwords and how to handle them. In this first installment I will go over two biggest errors you can make as far as password storage is concerned.

Definitely worst thing to do is to store plain-text password in database. This is just unacceptable. If any user gains access to your database all your users are compromised. Since most users tend to use same password for multiple purposes and web sites, compromising password for some internal application could also mean compromising password for Amazon or PayPal account.

Almost as bad is storing passwords using reversible encryption (DES, AES or similar two-way algorithms). While data looks properly encrypted it is still possible to get original password. If your program can get to password, so can somebody else. Always assume worst.

For storing passwords you MUST use irreversible encryption. For properly hashed passwords bad guys must resort to dictionary and brute-force attacks. Losing hashed passwords is also not desirable but at least you buy some time.

Cannot Contact Steam Network

Jeff Atwood has some strange hobbies that include (but are not limited to) giving away games. Fortunately I was on receiving end of latest giveaway. Condition was good score on one or more trilogy sites and steam account.

Installation of steam client wen’t without issues but program would not start. It would just give standard non-descriptive message “Cannot contact steam network”. For troubleshooting purposes I tested it in Windows XP Mode and everything worked there. That confirmed that compatibility with my Windows 7 (64-bit) is issue here.

Solution was annoyingly simple. I went into properties for Steam and checked “Run this program in compatibility mode” check-box. I opted for Windows XP compatibility (default) and started it again. Update went without hitch.

After update I got nasty message from Windows telling me that I should consider removing compatibility settings. Once I removed compatibility application continued to work but my download rate went to 0.0 KB/s. Going against all warnings I reactivated Windows XP compatibility and everything was good once more.

Worthless Precision

Calculations show that Earth’s oil reserves will cease to exist at 20:58 on Oct 22, 2047. It is scary figure to see and it is probably as good of an guess as any. Saying this, it is also just rubbish. I will explain on example of thermometer.

My new kitchen thermometer shows me temperature of 19.3 °C. I think that all thermometers that you can buy show results with one decimal digit (with resolution of 0.1 °C). However, once I checked specification, I was puzzled. Precision of measurement is only ±2°C. Simply said it means that actual temperature is anywhere from 17.3 to 21.3 °C.

It is in human nature to assume that all that is shown actually matters. I can bet you that people would trust thermometer with five decimal digits more (e.g. 19.24133 °C) than one without them (e.g. 19 °C). It just looks better when our numbers have higher resolution. Real truth is hidden in precision. And that number is not always easy to find.

Time of oil exhaustion is nonsense for same reason. They showed it with resolution of one minute just to make it more believable. Real precision is probably give-or-take few years if not more.

P.S. Yes, we will run out of oil one day. We just cannot pinpoint date.

BIOS Feature

I have mandatory BIOS password on my work computer. Some Catbert character thought of it as good security feature. Now, whenever I need to reboot my computer, I need to sit next to it.

I used to grab cap of coffee while it was rebooting and all I needed to do was to log into Windows once that is done. Now I need to sit next to it through whole shutdown process waiting for BIOS password and only then I can get a coffee. If there is some update in progress, that waiting period usually puts me in “I will kill this guy” state. I really hate waiting…

During that useless time my mind often wonders to my first Pentium-class computer. There you could set “stealth” BIOS password (I forgot official name of that feature). If such password was set, system would boot up without asking for anything. Everything seemed normal until you tried to use keyboard or mouse - they were locked. Only once you entered your password BIOS would release control of PS/2 ports and Windows would take over. Since Windows worked normally even without password, you could rely on this feature even across reboots.

I have pretty good idea why that feature is gone - USB. BIOS can intercept and handle PS/2 keyboards quite easily even once Windows are up and running. Since Windows talk with keyboard over BIOS, it can choose whether to pass characters or not. With USB things get complicated.

Once Windows take over USB control (and that is fairly early in boot process) there is no simple way BIOS can restrict it. Only approach that would work in that case would be some hardware virtualization. BIOS would have control over physical USB and Windows would get virtualized version controlled by BIOS.

I am quite sure that someone would do it if there weren’t three big problems - compatibility, performance and cost. Compatibility would be easiest to solve. Performance (latency) could be lowered by employing ASICs. However cost to do that would be high. And all that because of feature that is not that necessary to begin with.

Sometimes I long for simpler times… :)