February 27th, 2014, 04:39 AM
Converting password to number
As part of the login process for my game I am storing the username / password in a file. To protect this and stop people using the password I have written some code to take the password, convert this to ASCII code, preform two mathematical operations and save this to a file.
Having undertaken some testing of my code I have found a couple of things:
1) Entering "Paul" produces the same result as "luaP"
2) Entering "Lisa" produces the same result as "Bart".
Paul = 180730
luaP = 180730
Lisa = 178093
Bart = 178093
Here is the code I have written. This is taken from my game but changed slightly to work as a standalone program.
PasswordCreate$ = ""
length = 0
PasswordCreateText = 0
PasswordCreatePro$ = ""
Input "Enter a password: "; PasswordCreate$
length = len(PasswordCreate$)
for A = 1 to length
PasswordCreatePro$ = mid$(PasswordCreate$, A)
PasswordCreateText = PasswordCreateText + asc(PasswordCreatePro$)
PasswordCreateText = PasswordCreateText * 293
PasswordCreateText = PasswordCreateText + 62944
Print ""; PasswordCreateText
open "PassWordChecker_Temp.spf" for append as #UC
print #UC, ""; PasswordCreate$; " = "; PasswordCreateText
input "? "; RunChoice$
if RunChoice$ = "q" then gosub [EndOfTest]
notice "Program closed"
February 27th, 2014, 04:53 AM
are those actual passwords? Or is this just for fun?
If you're dealing with real passwords, I strongly suggest you stop playing with homegrown math and use an actual password hash algorithm like bcrypt.
February 27th, 2014, 04:59 AM
This is just for fun / learning in a game I am working on.
Originally Posted by Jacques1
March 1st, 2014, 03:12 PM
The commutative property of addition cripples your password algorithm.
A+B == B+A
Any permutation of Paul with any one of the letters capitalized will compute to the same value. Tamp should also match Paul since one of the letters has increased by the same amount another decreased. Passwords all computing to the same value, written in j from www.jsoftware.com
Rotating the bits of the computed hash before combining each next character will introduce a positional dependence to improve your function. The following demonstration does not prove that I've created a good hash function. It does show that my idea won't fail for the same trivial reasons your fails. If you don't read j perhaps the comments suffice to explain the sentences.
(62944 293 p. [: +/ a.&i.)&>;:'Paul pAul paUl aPul pLua Tamp'
180730 180730 180730 180730 180730 180730
rotate_bits =: 1&|.&.((16#2)&#:) NB. rotate 16 bit binary representation by 1 place.
rotate_bits^:(<17)1 NB. demonstrate the 0 through 16 rotations of 1
1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 1
NB. Insert addition of left number to 16 bit partial sum rotated by 1 bit
[HASHES =: (62944 293 p. [: (+ rotate_bits)/ a.&i.)&>;:'Paul pAul paUl aPul pLua Tamp'
533502 524126 505374 528521 504788 534674
(,&#~.) HASHES NB. prove the hashes are unique. (tallies agree)
Last edited by b49P23TIvg; March 1st, 2014 at 03:20 PM.
[/code] are essential for python code and Makefiles!