Sure, passwords alone can’t secure your Web-based system. But you can still take measures to make them more effective. For one thing, you can build in some functionality that forces your users to adopt strong passwords. You can also carefully consider where you store those passwords and take advantage of encryption classes to protect them.
Don’t dismiss the importance of using strong passwords. Sometimes, passwords are the only barrier between hackers and a series of potentially harmful operations. Strong passwords meet at least the following requirements:
- They’re at least eight characters long; 12 or more is better.
- They contain elements from any of the following groups: lowercase letters, uppercase letters, nonalphanumeric symbols (punctuation, *, #, $, and so forth), and digits.
- They expire frequently—every 90 days or sooner.
Password history and other constraints
You can require as policy that a password history be maintained to prevent the same password from being renewed over and over. Other, stricter rules are also possible, such as requiring certain elements to appear in specific positions within the password.
Of course, longer or more complex passwords do not eliminate the risk of brute-force attacks, in which hackers try all possible combinations of characters to guess the right password. Still, the longer thepassword is, the more time it will take to crack. This fact, combined with an effective auditing policy, should significantly increase the likelihood of detecting the attack.
Look at the numbers
If you’re not convinced of the importance of strong passwords, have a look at Table A, which shows the possible combinations of strings that a brute force attack must walk through to guess a password. Let’s say that you think a five-character password consisting only of lowercase or uppercase letters will suffice. Given a 26-letter alphabet, the number of five-character substrings is obtained through the following formula, in which the ! symbol denotes the factorial of the number:
26! / (26-5)! * 5!
The table shows how the number of combination changes according to the alphabet and the password length.
A hacker would probably employ an optimized combinatorial algorithm, making the effective number of attempts even smaller. However, my goal here is to show the order of magnitude by which your password security grows if you only make the password longer or add an extra group of characters.
Let’s say it up front: There’s no absolutely safe place in which critical data like a password can be stored. In normal conditions, having the password stored as plain text in a file is not a problem. However, if a successful attack occurs, your critical password will be there, ready to be stolen.
If the password serves to connect to SQL Server, you might want to opt for trusted connections and Windows and SQL Server integrated security. The connection string below is the one you would use. It doesn’t contain an explicit user ID and password. In fact, if you include them, they will be ignored. Windows and SQL Server work silently together to exchange and verify credentials of the logged on user.
In this case, you need to configure the ASP.NET account as a valid SQL Server login. Otherwise, you can store the password in a database or in a file located outside the Web application subtree. Again, this won’t give you the 100 percent guarantee of inviolability, but it certainly makes it harder to hack the system.
Encrypting the password can also be helpful, since it adds another layer of complexity. But don’t try to run your own encryption algorithms thinking it will be more secure. (Do not overvalue yourself!) Serious hackers can break naïve schemes in a few hours. If you opt for encryption, don’t be scared to use the .NET Framework cryptography model. You don’t have to be an expert to use those classes.
The .NET Framework provides implementations of many standard cryptographic algorithms. To encrypt and decrypt data, you must use a key with an encryption algorithm that transforms the data. There are two main families of algorithms: symmetric and asymmetric.
Symmetric algorithms have a single key and use it for both encryption and decryption. Only the sender must know the key. It travels with the data so that the data can be decrypted when it reaches the receiver. The DESCryptoServiceProvider class is an implementation of a symmetric algorithm.
Asymmetric, or public key, algorithms require that both sender and receiver maintain a pair of keys: a public key and a private key. The public key can be made available to anyone and is used for encoding data that is sent to a receiver. The private key must be safely stored and is used only for decoding messages encoded with the sender’s public key. Anything encrypted with the public key can be decrypted only with the companion private key. So I should first ask you to send me your public key. RSACryptoServiceProvider is an implementation of an asymmetric algorithm.
Typically, symmetric encryption is performed on streams and is therefore useful to encrypt large amounts of data. Asymmetric encryption is performed on a small number of bytes and is therefore useful only for small amounts of data, such as a password.
More on encryption
The kind of passwords you employ and where they are stored are crucial to the design of your Web-based application. Build some additional password functionality into your application, choose your storage location carefully, and take advantage of encryption classes in your platform—be it .NET or Java.
What do you think of strong passwords? A Web app no brainer or overvalued proposition? Post your comment below.