Following on from my earlier email - I've the following question now :
I can enforce that the user can't use the same password as the previous four
- when they change their password. However, the user can manipulate this by
changing the password four times and then resetting back to there original
password. How would I overcome this problem ? Any thoughts or
On Tue, Jan 19, 2010 at 9:14 AM, Tompkins Neil <neil.tompkins@stripped
> Thanks for all the replies. For your information, we are going to store
> passwords using SHA256. I think I will go with the four additional column
> approach as I proposed (in the current table) - since this need is a PCI
> compliancy security requirement. I can then pull all the data with one
> I don't envisage that we will need to record the last 20 passwords as a
> example in the future - so if I need to expand in the future it should not
> be too involved.
> On Tue, Jan 19, 2010 at 1:11 AM, Carlos Proal <carlos.proal@stripped>wrote:
>> On 1/18/2010 6:52 PM, Colin Streicher wrote:
>>> On January 18, 2010 01:34:15 pm Tompkins Neil wrote:
>>>> I'm in the process of designing a login system to a secure web page
>>>> MySQL. One of the features is we need to record and ensure that the
>>>> password is different from any of the last four passwords he/she has
>>>> I was thinking of create four fields called Password1, Password2,
>>>> Password3 and Password4 to record the old passwords.
>>>> Is this a preferred method - or does anyone else have any
>>>> recommendations ?
>>> I'm not an awesome database designer, most of what I do is code related
>>> I think what I would do for this is 1. hash the password( sha256/512
>>> and then 2. store the hash in a string with delimiters. In that way, you
>>> 2 problems.
>>> You can store as many as you want to because you can just check hashes to
>>> sure it isn't the same, and second, you aren't storing passwords in
>>> text, which is a personal pet peeve.
>> As others appointed, having another table with old passwords is a good
>> "design" solution, and can allow you to have more than 4 passwords on your
>> history. But in fact your solution is the best solution for performance and
>> is called "denormalization", this solution gives good performance because in
>> 1 read you get all the passwords but has the limitation of be "fixed" to
>> only 4 passwords (which is not so bad because you can add new columns as
>> needed, you will never have 20 history passwords anyway, do you ?).
>> So, thats the trade, design vs performance, you should pick the best for
>> The solution proposed by Colin is another way to do it but, from the good
>> design perspective is NOT a good solution, is what its called a "multivalued
>> attribute" and all those should be avoided. But again, is up to you.
>> MySQL General Mailing List
>> For list archives: http://lists.mysql.com/mysql
>> To unsubscribe: