Passwords, Security , Caching, Google Safe Browsing API

Post date: Dec 5, 2011 11:51:16 AM

First the shorter list:

• Wrote a guide to proper password policies, with nice examples.
• Wrote a guide to configuring systems securely. - I did find major issues, which I can't tell more about.
• Added CAR caching on application instance level to 9ox.net, just for fun. Memcache is usually better for apps with low loads than in instance caching? Why? Instance memory / cache is lost when instance dies, but memcache remains. But in instance cache is very much faster to use than memcache, so for highly loaded apps it's a must!
• Studied Google Safe Browsing API, but I didn't have time to implement it yet.

Some thoughts about passwords. These matters are covered in different net discussion forums (and LinkedIn) over and over again.

I see here a lot of discussion about passwords and hashes. But as far as I can see, I still didn't find out any mentions about using salt and preferably better encoding/storage method than just plain MD5 or SHA-1. There are alternatives like bcrypt and scrypt, which make hacking passwords even with "hash", much harder and slower. One basic trick is just to use salt and many hash iterations. If password is mixed with hash and 4 million SHA-1 iterations, it'll take one modern CPU core about one second to try one password. It'll make cracking passwords very much slower while simultaneously makes rainbow tables totally useless. But of course if some one already got the hashes, we already had a very big problem. A major data leak. If they could use SQL injection to steal hashes, it could have been as well possible to steal all data from database protected by those passwords. Main problem with hash password cracking/password leaks is that people are using same password for several sites / services. That's extremely bad policy. I personally use (minimum) 16 character random passwords for each separate service. I know this won't protect me from key loggers, for that we need two factor authentication. Even in that case, if system is infected with malware, they can use my system as proxy to access the data when I'm properly logged in. So even that won't give perfect protection. Some bank trojans have been doing this for a quite good while. If you got malware on "your" computer, it isn't "your" computer anymore.

Even if passwords (or hashes) aren't leaked or stolen. It should be up to each sites policy to prevent password hammering. Even if it's a lot slower. It still can work out if people are using bad passwords. IPs which are used to try login all the time should be blocked for some length of time. Depending from service and user account type, locking account might not be a good idea, because it would cause user to be unable to log in even with proper credentials. It's also beneficial not to tell if account is locked or not and if user name or password are invalid. Login failed, should be same message returned for what ever reason. Then they can't first can for user accounts and then for passwords, because they don't know when they got right user account hit. Some services clearly tell that userid or password was invalid. Which isn't a good practise.

Do not forget using encryption, because it's very easy to steal passwords (or any data) from LAN, if encryption isn't being used. Every site with requires login should always use https. Because even if https is dropped after login the password can't be stolen easily, stealing the session authentication cookie and all data is trivial. So it's clear failure, if https isn't used all the time.

If complex passwords are copy pasted, it might also be major security problem. You don't need root access for stealing data from clipboard. So any user space application could steal passwords if clipboard is used to transfer those from secure storage to browser or any other login screen.

This is hard topic for even IT-professionals, and way harder for people who doesn't even bother to think about these matters at all. I would recommend using at least 12 character long "semi-random" passwords, which do not contain any known words in any language that could be found from any dictionary. Passwords must be are service specific, sharing is absolutely forbidden.

P.S. You don't want to believe how many systems store passwords in plain text nowadays. Even as stated earlier, it's not a real problem, unless users use same password for multiple sites / services.