Password policy for user accounts

Posted in others/ on March 18, 2010 by Marcus.

My situation

You might have heard that I've lost my beloved smartphone. Due to this, I assume the person that found it might have got hold of several user accounts of mine.

In the last days I've revoked several SSH keys, changed credentials of server accounts and changed passwords of several accounts on websites.

If you ever come into this situation, you should start with your e-mail accounts. They usually contain your most private information, confirmations of account creations and perhaps passwords of user accounts. Then move on to e-commerce websites and change passwords there. Finally, change passwords of any other user account.

Of course, you should not have one password for all of your accounts. Before you ask, no I haven't had a one and only password for all of my accounts.

 

A draft of an ideal password policy

By changing my credentials, I stumbled over websites that have not any user interface to change passwords (contact support), websites that hide the user interface in the FAQ section, websites that allow only alpha-numeric passwords and nearly perfect websites in regards to password policy.

If you're building websites with user accounts, following suggestions will help you to make password policy user friendly.

• If the account requires an e-mail address, do not allow the user to change the address via an user interface! Such change should always require the user to contact the support. The support should verify the identity of the user requesting this change and might wait mandatory three days before applying the change. The support should send a notification mail to the old e-mail account that informs about the planned change of e-mail address. This period allows the account holder to interfere in case of credential compromise when the change request was initiated by the bad guy.
• Do not hide the user interface for changing the password. It should be part of a account/settings webpage reachable via one click!
• The interface of the password change should consist of one field for the old password and two fields for the new one (one for confirmation preventing spelling errors).
• Allow alphanumeric AND special characters for the password!
• Put a description text to the password fields that tells the user what kind of characters are allowed.
• Divide possible characters in four classes: numeric characters, lowercase alphabet characters, uppercase characters and special characters. Require at least three classes to be chosen from for the password and a minimum length of the password string.
• Put a graphical representation of the password strength next to the password field. This should calculate the mathematical entropy of the password string. Red, orange and green are nice colors to represent the strength.
• Inform the user via mail about the change of his password along with the IP address of the host that initiated the change!
• Do not send passwords via mail!

I've found out that Amazon and Ebay are nearly perfect in regards to password policy. It's up to you to take my suggestions and improve your website!

I'm awaiting your comments; any important point missing?

Beware of Subversion leftovers in production websites

Posted in others/ on November 03, 2009 by Marcus.

Every once in a while, old and known problems are newly discovered. The same recently happened for the Subversion leftover issue.

If you checkout projects from a Subversion server, subversion creates a ".svn" directory that contains some data. Using this ".svn" folder, subversion is able to determine if local changes have been made, etc ...

In case, your webserver does not reject access to ".svn" folders, a malicious user will have access to listings of webserver directories even if you try to prevent that with the "DirectoryIndex" directive. In addition, a malicious user might get hold of unparsed script code in plain text depending on your webserver configuration.

There are at least two valid solutions:

• Use dedicated command "svn export" for deployments and you'll receive a clean directory tree.
• Reject access to ".svn" folders in your webserver configuration.

A valid entry in your Apache config file (httpd.conf/apache2.conf) would look like this:
#
# Prevents access on SVN specific folders
#
<Directory ~ ".*\.svn">
    Order allow,deny
    Deny from all
</Directory>

Off-topic: Going online with o2 mobile

Posted in others/ on July 15, 2009 by Marcus.

After having canceled one of my mobile phone contracts I took the change to actual check recent bills. That was quite surprising (should have done this earlier!).

o2 Germany by default offers two different billing methods (there are further packages that require a monthly fee); per volume and per time. It seems in March 2008 I canceled an addon package (email stuff) and accidentally switched to volume based billing.

This made me pay 9,22 EUR per MB (1 MB could be one page on a website with a few images). Curious as I am, I calculated that for this 1 MB I could be online with time based billing for 102 minutes (billing is 0,09 EUR per minute). 102 minutes would result in 5,5 GB transfer with offered (theoretical) maximum speed of 7,2 MBit/s.

Paying about 9 EUR and getting 1 MB with volume based billing versus 5,5 GB in time based billing!! What would you choose? Interesting business model, isn't it?

I still wonder if there's any use case where choosing volume based billing is cheaper than time based billing? Like connecting to a web server and sending keepalive packets only every two minutes?

At least, after presenting the figures (1 MB vs. 5,5 GB), o2's Customer Care gave me a little refund. I'm now using a package with a monthly fee but "unlimited traffic". Stupid me.

TYPO3 at the LinuxTag

Posted in others/ on June 17, 2009 by Marcus.

Meet TYPO3 Core and Security Team members

On June 24 - 27, 2009, there's the 15th LinuxTag in Berlin (Germany). Amongst other Open Source projects, TYPO3 will be present with a booth.

If you are going to visit the LinuxTag or in case of questions regarding TYPO3's current and future status, make a visit at hall 7.2A, booth 113B!

TYPO3 Core Team members will welcome you the whole four days. Answers to TYPO3 Security questions will be given on friday.

We're looking forward to meet you!

Thanks for the order!

Posted in others/ on June 13, 2009 by Marcus.

Whoever ordered the book PHP-Sicherheit via my amazon link - thank you for that. You won't regret it.

Of course, I also have this book in my bookcase. The co-author is Stefan Esser, reporter of a lot PHP-vulnerabilities, initiator of the month of PHP bugs and maintainer of the suhosin project.

The book is a must-have for administrators (of PHP applications) as well for PHP developers.

It starts with a chapter explaining how an attacker will work on getting as much information as possible of a to be attacked host. Besides that all types of vulnerabilities are explained. The authors give advices on how to harden your PHP installation and how to produce secure code. Finally, the authors present projects like suhosin as well as filter/IDS solutions like mod_security with whitelist or blacklist approaches.

It's worth every Euro!