On 04/23/2014 02:12 PM, Kevin Cully wrote:
On 04/23/2014 05:05 PM, [email protected] wrote:
Minor comment: you'd want to look to go to nMyHashIterations - 1
since you do the 1st one before the FOR loop.
As long as the program is consistent, it's all good! :D
Would you encrypt the nMyHashIterations value stored in the Passwords
table? Otherwise, using your scenario, the thief would see the # of
iterations you've used. This is where you'd just store the
MyEncryptRoutine(nMyHashIterations) value to that
Passwords.nIterations field, if I'm following you correctly.
You could encrypt the nMyHashIterations in another table if you'd like.
I'll leave that up to you on whether that's necessary. I'd create a
function somewhere that would increase the nMyHashIterations and set the
flag forcing all users to reset their password. Hopefully you'll never
have to use it.
I do have a tstamp field that's a timestamp value showing me when the
record was added; that could come in handy for such theory as you
state above. Did you pick 30 and 42 randomly, or was there something
specific about those values?
I wouldn't store any information with the password at all. This keeps
all values in the table of equal possibility that it is a valid
password. You don't want anything that would allow the bad guys to
whittle down the time they would need to take to hack your password
system. Remember, if they gain physical access to your data, all bets
are off for system security. If they gain console access to the server,
all of your efforts are for nothing. Once a computer is infected or
compromised, no amount of cleaning / anti-virus / anti-malware can
restore your trust in that installation.
The values of 30 and 42 were just random examples. As computer hardware
gets more powerful, then the iterations can be increased. Perhaps some
day, you'll have iterations in the thousands or millions. Of course,
Windows would just add a 'glitter sparkle' effect to the server UI that
would rob you of all of these performance advances, but that's just me
being a crotchety old man. :D
Question & Thoughts. First, please no comments re: the fact that I am
using Foxpro 2.6 under Ubuntu/Dosemu.
Question: How secure is the encryption of the .fxp files created by fpd
2.6. I use it to encrypt constants.
With a small number of users, mine is about 10, in the code I could
create a constant salt value for each user. I found that the sys(2015)
value created is real time clock sensitive. I would delete the first 3
characters before using it.
I will be adding a string made up of the characters on the 'Rainbow
List' to make sure the users do not use these. I also store the hash (I
use the crc function) of the previous password as a variable in my
program so they don't change it from the current password to the new
password. I do not store the previous previous hash and check it so
they don't bounce back and forth every 3 months.
I also use a multi-type of lookup dbf (cities, counties, police dept,
etc.) so the actual database has less info in it that can ID the nad data.
I am still struggling with encrypting data using the character change
method when I have account numbers that are in sequential order.
(that's a solicitation for ideas :) )
John
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
