salt

This question has to do with PHP's implementation of crypt() . For this question, the first 7 characters of the salt are not counted, so a salt ' $2a$07$a ' would be said to have a length of 1, as it is only 1 character of salt and seven characters of meta-data. When using salt strings longer than 22 characters, there is no change in the hash generated (i.e., truncation), and when using strings shorter than 21 characters the salt will automatically be padded (with ' $ ' characters, apparently); this is fairly straightforward. However, if given a salt 20 characters and a salt 21 characters,

Update: Please note I am not asking what a salt is, what a rainbow table is, what a dictionary attack is, or what the purpose of a salt is. I am querying: If you know the users salt and hash, isn't it quite easy to calculate their password? I understand the process, and implement it myself in some of my projects. s = random salt storedPassword = sha1(password + s) In the database you store: username | hashed_password | salt Every implementation of salting I have seen adds the salt either at the end of the password, or beginning: hashed_Password = sha1(s + password ) hashed_Password = sha1

I came across a discussion in which I learned that what I'd been doing wasn't in fact salting passwords but peppering them, and I've since begun doing both with a function like: hash_function($salt.hash_function($pepper.$password)) [multiple iterations] Ignoring the chosen hash algorithm (I want this to be a discussion of salts & peppers and not specific algorithms but I'm using a secure one), is this a secure option or should I be doing something different? For those unfamiliar with the terms: A salt is a randomly generated value usually stored with the string in the database designed to make

So I was experimenting with bcrypt. I have a class(shown below, which I got from http://www.firedartstudios.com/articles/read/php-security-how-to-safely-store-your-passwords ) in which there are 3 functions. 1st one is to generate a random Salt, the 2nd to generate a hash using the 1st generated Salt and the last one is to verify the supplied password by comparing it with the hashed password. <?php /* Bcrypt Example */ class bcrypt { private $rounds; public function __construct($rounds = 12) { if(CRYPT_BLOWFISH != 1) { throw new Exception("Bcrypt is not supported on this server, please see the

I think I'm missing something critical here. In the CPasswordHelper::hashPassword function we have lines: $salt=self::generateSalt($cost); $hash=crypt($password,$salt); return $hash; And in the CPasswordHelper::verifyPassword there is this line: $test=crypt($password,$hash); return self::same($test, $hash); What about the salt? To my understanding its not even beeing kept, but it doesn't make any sense, so I'm guessing I didn't understand it completely. CPasswordHelper works like PHP's functions password_hash() and password_verify() , they are wrappers around the crypt() function. When you

Suppose you were at liberty to decide how hashed passwords were to be stored in a DBMS. Are there obvious weaknesses in a scheme like this one? To create the hash value stored in the DBMS, take: A value that is unique to the DBMS server instance as part of the salt, And the username as a second part of the salt, And create the concatenation of the salt with the actual password, And hash the whole string using the SHA-256 algorithm, And store the result in the DBMS. This would mean that anyone wanting to come up with a collision should have to do the work separately for each user name and each