Hi Rick,
I would appreciate your advice on this.
With switching to webconnect 7.0, I still need to use my old encryption which uses EncryptString but I'd like to keep everything else just as is in wwUsersecurity. So I'd like to maintain the idea of re-encrypting pw after each logout if it doesn't end with a special character.
As far as I see for the current encrypted strings, all strings<=15 char get encrypted ending with "=", would you think if this is a correct assumption for EncryptString that the "=" will be always there and can be used as my special character or should I add another one manually and adjust all old codes to take care of it?
Thanks,
Kathy
You most definitely can not rely on the =
at the end of the string. That's a base64
encoding artifact and it may or may not have that at the end.
The way you can do this is to explicitly add a postfix or prefix to the encoded string yourself when you store it. Use unlikely characters like ~!~
and append them after encryption. You can strip off the postfix/prefix when you decrypt and when checking the value on whether it's encrypted or not check for the postfix/prefix in the string being present.
You can look at the code in wwUserSecurity
which does just that for its encryption although it only does (one way) hashes:
FUNCTION GetPasswordHash(lcPassword, llForce)
LOCAL lcEncrypted, loEncrypt
IF EMPTY(this.cPasswordEncryptionKey) OR EMPTY(lcPassword) OR (!llForce AND EndsWith(lcPassword,"~~"))
RETURN lcPassword && already encoded
ENDIF
IF (this.lCaseSensitive)
lcPassword = LOWER(lcPassword)
ENDIF
loEncrypt = CREATEOBJECT("wwEncryption")
lcEncrypted = loEncrypt.ComputeHash(lcPassword,"HMACSHA256",this.cPasswordEncryptionKey) + "~~"
RETURN lcEncrypted
ENDFUNC
Sorry if I had to come back to this.
I feel kind of lost among the formulas on the internet.
I need to give a limit for user password length in order to store encrypted passwords in the database.
It's because some of the end users are using short sentences as their password!
So if the password field is set as 35 char in database, could you please tell me what the user password length should be? I'll need to save 2 or 3 space for the unlikely characters as well.
Many thanks,
Kathy
Storing passwords in a database is a big no-no, encrypted or not!!!
Instead, store the hash value for the password in the database.
Encrypted password size will change, but it stays fairly consistent when you use a max length of characters. You'll have to experiment if you want to hit your maximum DB size. Create long passwords and then play around with different sizes until you get around 35 characters encrypted. Keep it a little below.
However, if you're using SQL Server (or most other databases including FoxPro) you are better off using a longer varchar field and just letting varchar dynamic storage deal with the sizing. You can control the text input size at the input box, and then make sure that the DB can hold the longest value you want to store.
If I recall all the SHA hashes will produce fixed size lengths regardless of how many characters you pass. SHA256 produces 64 chars in BinHex mode, and 44 in base64 mode.
DO wwEncryption
LOCAL loE as wwEncryption
SET MEMOWIDTH TO 255
loE = CREATEOBJECT("wwEncryption")
loE.Setbinhexmode()
lcAlgo = "SHA256" && SHA512
? loE.computehash("1",lcAlgo)
?
? loE.computehash("12345",lcAlgo)
?
? loE.computehash("54321",lcAlgo)
?
? loE.computehash("12345123451234512345",lcAlgo)
?
? loE.computehash("54321543215432154321",lcAlgo)
?
? loE.computehash("1234512345123451234512345123451234512345",lcAlgo)
?
lcHash = loE.computehash("5432154321543215432154321543215432154321",lcAlgo)
? lcHash
? LEN(lcHash)
All hashes are the same when using SHA algorithms because they pad. But even SHA1 is longer than 35. In wwUserSecurity I use HMACSHA26
for hashed passwords and a varchar field length of 80 characters. This handles the 64 bytes + the 2 marker characters to idenitify as encrypted.
Note that using Base64 mode is more efficient and produces smaller character counts (using SetBinHexMode(.f.)
) but it's still 44 characters for SHA256
.
That's a lot of space, but that's the price for security.
+++ Rick ---
Thank you so much Tore.
Kathy
Thank you so much for all steps and details.
It was very helpful.
Kathy