security

How to secure a websites user database?

Posted on by Savagedlight

How often haven’t you read about entire user databases being retrieved from vulnerable websites? And how often do people use the same password multiple places? Let me answer both those questions: too often.

Let us assume that Ada is running a website for her guild. She has decided to code the thing from scratch, and are about to implement the user management system. She decided she’d only need to store username, password, and user type in the accounts table.

She knows that storing passwords in plain text is unacceptable, and think they need to be hashed. Therefore she decides to store the MD5 hashes of the passwords. When someone try to log in, the code checks if the MD5 hash of the specified password is equal to that stored in the database. She’s thinking that if someone somehow attained a copy of the users table, they wouldn’t get to find the real passwords in a sensible amount of time because the passwords are hashed and they’d have to mount a brute force attack to obtain it.

She’s wrong. A direct hashing of a password is vulnerable to rainbow table attacks. While a few conditions apply, this method makes the process of retrieving the password from the user database instant. Even though she didn’t store the passwords in plain text, they’d still be easily exposed. Knowing this, she decide to salt the passwords. This means the password will be modified in some way before being turned into a hash; usually by adding some string to the end of the input password. She knows of two ways to do this.

Continue reading →

Password Tips

Posted on by Savagedlight

After having read many articles with password tips, I’ve come to the conclusion that painfully few are aware of the painfully obvious.

So here goes!
First order of business: Forget about the password, start thinking of the pass phrase. Like it or not, a short sentence can easily be more secure than a complex password. Example 1: Randomly generated password: “Tda,%Bn&x+in”. This has an entropy of 12 upper/lower-case characters, numbers and special signs. It’s also pretty much impossible to remember.
Example 2: “I huggled an owl while sitting in a tree!” has an entropy of 41 lower/upper-case characters and special signs.

Continue reading →

FreeBSD: kern.securelevel

Posted on by Savagedlight

Quoting the security(7) man page: The kernel runs with five different security levels. Any super-user process can raise the level, but no process can lower it.

The security levels are:

  • -1 Permanently insecure mode – always run the system in insecure mode. This is the default initial value.
  • 0 Insecure mode – immutable and append-only flags may be turned off. All devices may be read or written subject to their permissions.
  • 1 Secure mode – the system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem and /dev/kmem may not be opened for writing; /dev/io (if your platform has it) may not be opened at all; kernel modules (see kld(4)) may not be loaded or unloaded.
  • 2 Highly secure mode – same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with file systems by unmounting them, but also inhibits running newfs(8) while the system is multi- user. In addition, kernel time changes are restricted to less than or equal to one second. Attempts to change the time by more than this will log the message “Time adjustment clamped to +1 second”.
  • 3 Network secure mode – same as highly secure mode, plus IP packet filter rules (see ipfw(8), ipfirewall(4) and pfctl(8)) cannot be changed and dummynet(4) or pf(4) configuration cannot be adjusted.