Continuous Deployment

Continuous Deployment can be thought of as an extension of continuous integration, aiming at minimizing lead time, the time elapsed between development writing one new line of code and this new code being used by live users, in production.

Continuous deployment is controversial. Most people, when they hear about continuous deployment, think I'm advocating low-quality code. On the contrary, I believe that continuous deployment requires tremendous discipline and can greatly enhance software quality, by applying set of standards to every change to prevent regressions.

To achieve continuous deployment, the team relies on infrastructure that automates and instruments the various steps leading up to deployment, so that after each integration successfully meeting these release criteria, the live application is updated with new code.

Instrumentation is needed to ensure that any suggestion of lowered quality results in aborting the deployment process, or rolling back the new features, and triggers human intervention.

Benefits

• Earlier return on investment for each feature after it is developed, which reduces the need for large capital investments

• Earlier feedback from users on each new feature as it is released to production, which affords techniques such as parallel (or A/B) testing to determine which of two possible implementation is preferred by users

Pitfalls

• To the extent that continuous deployment is viewed as a strategy for quality, it's easy (in particular for developers enamored with the novelty and technical aspects of it) to pick the wrong target, and optimize for "maximum frequency of deployments" - that will not, by itself, result in increased quality.

Password Storage Mistakes

Passwords are suppose to be a secure way for authenticating users of a system. 
Every developer must provide a secure and reliable way for storing passwords. There are quiet a number of ways to go about it.

Storing passwords using reversible encryption means that my password may be decrypted. Someone who has access to the application's system and key, may also readily access my password and the thousands of users at this site. One compromise of the key and ALL passwords are toast.




Hashing

So passwords are not to be stored in plain text, they are not to be stored in encrypted form. Well, password can be hashed, Lets review this.

Hashing, which results in a message digest, is a one-way operation. When a hash table is calculated the input is provided and the result is a fixed length output. The SHA-512 algorithm has a 64 bit output, The SHA-256 has a fixed 32 bit output and bcrypt algorithm has a fixed 60 byte output. For each of these algorithms there is an infinite number of potential inputs, but a finite number of potential outputs, this is called collision. Good cryptographic algorithms make it difficult to find collisions.

So by hashing a password, we've solved the password storage problem. But the problem isn't solved yet. People do crack passwords. Unfortunately, while hashing is irreversible, passwords that have been hashed can still be cracked. A number of cracking methods can be used, including brute force, rainbow tables or password dictionaries. During a password attack, looking up hash value in rainbow table is much faster than hashing and comparing each value in the password dictionary.

Salting

Sometimes you need a little something special to make storing passwords better. Lets say I have a password "abcde". This would easily be cracked, any rainbow table or dictionary attack could be used to find this password. but suppose the developers before they hash the password, append a large random string (aka salt). So rather than calculating the hash for abcde, they instead store the large random character string (salt) along with the password. When the application developers decided to use salts when hashing, they effectively made my trivially simple password much more complex and made it very unlikely that someone could crack the password on a pre-computed dictionary attack or through the use of a pre-computed rainbow table. Rather, with a sufficiently large random salt, an attacker must create a separate dictionary or rainbow table for each user's password they are trying to crack. This is extraordinarily expensive and that is why strong salts effectively break dictionary attacks and rainbow tables.

Well there are several other ways for storing passwords. Feel free to explore them.