Targus Laser Presentation Remote

As I prepared my WinDays presentation, I noticed that I was missing one key piece of hardware - wireless presenter. While I could jump back and forth toward my keyboard, I decided to take lazy way out and to buy cheapest presenter that I could find. My choice fell on AMP13EU (AMP13US for U.S.A. market) priced at $50.

First sight was spoiled by indestructible plastic package. It took five bazooka shots to open it half-way. Once I opened it, everything got better - batteries ARE included. As I was inserting batteries inside I noticed that only one battery is really needed. You will get two batteries. There will even be place for two batteries inside, but only one battery has electric contact. Other one just sits in it’s compartment as emergency spare. Great idea.

In between batteries there is one additional compartment with small USB receiver. I am usually nervous about loosing such small USB thingies but place for storage inside of presenter made me feel little bit easier. It is not as comfortable as having bluetooth based one but this at least works with Windows Server 2008.

USB was immediately recognized as “Human Interface Device” and system thought of it as generic keyboard. Previous/Next slide buttons are interpreted by Windows as PageUp/PageDown keys and they can be used in any application. If you are Apple fan, support for KeyNote and PowerPoint keyboard shortcuts is available via small hardware switch.

As buttons go, on top you have standard next and previous slide buttons, start/stop presentation, blank screen and laser pointer. On side there is on/off and lock button. Locking device disables all buttons except next, previous and laser. I do like this mode just because of color changes (yes, I am that shallow :)) but I do not find it particularly useful otherwise. Buttons are spaced quite nicely so there is little if no chance of accidental key presses.

Front of device is polished black (a.k.a. as shade that attracts fingerprints) while background is rigged. While I prefer gummy finish myself I also must admit that device wasn’t slippery even in wet hands.

I am not sure about official range for device but it seems to be quite large. During my presentations I moved something like 10 meters from computer and it was still working. I do not think that I need more than that.

Only real problem I had with device is turning it off since you must press on/off button for couple of seconds. Since there is no visual feedback on “shutdown” status this usually results in more than one attempt.

Device did it’s job and I must recommend it for that. There are no advanced features (e.g. mouse control) so I am not sure whether it will be good fit for advanced presenter but for me it is more that enough. And, if they added storage “baggie” in packing it would be near to perfect.

P.S. If you are not interested in laser pointer or any other feature except for next/previous slide, AMP18EU (or AMP12US) has pretty much same features while being slightly cheaper.

Requirements for Password Hashing

Proper password hashing should satisfy few requirements.

First requirement is proper salting. I already wrote about this so check that post for explanation. I will just say here that properly implemented salting strengthens password against whole range of brute-force attacks. Storing password without salting is just not acceptable.

Second requirement would be using proven algorithm. Very often people (myself included) fall into trap of using easiest way there is. In case of password hashing this is usually just SHA-1 hash function. While this is definitely better than plain-text passwords, it is not ideal. Password hashing is just not that simple. Minimum would be support for RFC 2898 password derivation (both PBKDF1 and PBKDF2 will do). For this purpose .NET offers Rfc2898DeriveBytes class.

RFC 2898 also defines way to make your password hashing slow (via iteration count). Although every programmer wants code to run fast, exact opposite is required for password hashing. Idea behind it is to slow-down dictionary attacks. It is huge difference between trying out 10 and 1000000 passwords per second. Of course, you also need to think about users so some compromise is needed. There is no exact figure but I find anything sub-500 milliseconds acceptable to users.

Last requirement that I would add is using user name as part of hashing process. This is to protect us from “copy/paste” attacks if user names and hashes cannot be secured (e.g. in database table). If user name is not encoded, one could copy known password1 hash from user1 to user2 (overwriting password2 in progress). After that it will be possible to login as user2 with password1. That allows user1 to potentially create mess and blame everything on user2. If he restores old password2 afterward, you have security breach that is not easily traceable.

If you are not in mood for implementing this, you can download example of my implementation.

I opted for 9-byte salt and 20-byte key. That results in 30 bytes of output (first byte is iteration count). With base-64 encoding resulting string is exactly 40 bytes long.

8192 iterations should cause function to be around 500 milliseconds on most computers (@ 3GHz). This was selected as user’s psychological limit on waiting. Since number of iterations is stored in first byte of hash (12 for 4192 iterations, 13 for 8192, 14 for 16384 and so on) you can also speed-up (or slow-down) code by factors of two and retain compatibility among different versions.

User name string is converted to upper case before hashing (or checking). This causes user name to be case-insensitive even when encoded.

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.