I have started to realize that there are a few things I do that most average users do not to stay secure. I use a password manager (Roboform) that integrates with my browser. This tool makes me remember one master password and then allows me to fill in login forms on websites with only needing to know one master password. This has let me use unique passwords on all the sites I login to. I see looking through my list of sites that I have 45 accounts on various sites and there is no way that I...

One of the most common flaws I am seeing in applications is the lack of mutual authentication. Most systems authenticate that the user connecting to their system is a valid user. What is lacking is that the client verifies that it is connecting to who it thinks it is connecting to. One of the big examples of this is WiFi. If I have a wireless router named "myrouter" and set my laptop to use that router things work great. If I go down the street and someone else has a router named "myrouter", my laptop automatically tries to connect to...

One common attack to get into a website is to brute force the username / password. This is effective mainly due to the lack of brute force countermeasures that people build into their websites login mechanism. There are a few common countermeasures out there currently. Account Lockout An account lockout is when a set number of failed attempts are reached that no more attempts are allowed. Usually this involves flagging the user account in your database as locked out. While this stops a brute force attack in its tracks, it does have some consequences. The most obvious is that there will need...

Much to my disappointment PHP installs with developer settings by default. This means that the default installation has some potential security holes that need to be tightened after the install. Any security person will tell you that an application should install in a minimal and locked down  state. I would say 95% of people don’t look to secure something after they install it, they expect it to be secure out of the box. This is what IIS now does and you have to enable any features over the baseline you want. ...

*DISCLAIMER: This is only a theoretical idea. I have not confirmed that this could increase security of an iterative hash. Please take that into account when reading this. I was explaining iterative hashing the other day and came up with an interesting theory: Using a weak algorithm may result in a stronger hash. The reason for this is collisions that can happen in algorithms like SHA0, SHA1, and MD5 (a collision is when two separate strings yield the exact same hash). By using a collisionable algorithm in an iterative hash we could potentially throw an attacker way off. ...

Had an interesting thought today. If someone tries to brute force your login screen then why not after so many failed logins redirect them to a page that looks legitimate. This would cause the tool they are using to report that they cracked the password and logged in. The attacker would then have physically verify the login only to see some garbage page and start all over again. This would probably make a script kiddie attack some other site as they would probably not have the programming knowledge to alter the brute forcing engine. I would have it so...

Many times we need to have a way for users to authenticate with a system and that is usually done with a username/password combination. A lot of times we have to build our own or use some pre built system (i.e. Forms Authentication). Now I am not a fan of passwords. I find that they are usually easy to guess and brute forcing them has become faster and faster. Passwords are dying and there are other options but they will differ from implementation to implementation. If you have to build a password based authentication system then...

Talking with other developers and clients it amazes me how many people store credit card numbers in their systems. There is usually no need to store a full credit card number in your own database. It should be forwarded on to the processing gateway and then the information should be purged from your system the instant the transaction is complete. The Credit Card Companies Stances Contrary to popular believe you are allowed to store credit card information. The companies do have standards that you need to follow if you are storing this information. More information on this standard...

Although we are not qualified to do it, the fact is a lot of the time we are the technical people in our shops and are the ones who have to setup a new server. Because we can't know everything we can sometimes leave some things insecure. Here is some of what I do to harden a stand alone web server: Reduce The Attack SurfaceThe fewer entrances into a building means the fewer points an attacker can enter. Disable any unnecessary services If possible limit access to services by IP address (i.e. if you only remote desktop from...

Hopefully I have driven home the facts that salts are an important part of keeping a hash secure. We have done this using the strong random number generator of RNGCryptoServiceProvider. Now just because we applied a salt does not mean that our hash is rock solid. The hash and salt usually sit next to each other in the database/file they are stored in like so: UserId UserName Hash ...