[CreatePassword]
PasswordCreate$ = ""
length = 0
PasswordCreateText = 0
PasswordCreatePro$ = ""
cls
Input "Enter a password: "; PasswordCreate$
length = len(PasswordCreate$)
for A = 1 to length
PasswordCreatePro$ = mid$(PasswordCreate$, A)
PasswordCreateText = PasswordCreateText + asc(PasswordCreatePro$)
next A
PasswordCreateText = PasswordCreateText * 293
PasswordCreateText = PasswordCreateText + 62944
Print ""; PasswordCreateText
open "PassWordChecker_Temp.spf" for append as #UC
print #UC, ""; PasswordCreate$; " = "; PasswordCreateText
close #UC
input "? "; RunChoice$
if RunChoice$ = "q" then gosub [EndOfTest]
gosub [CreatePassword]
[EndOfTest]
notice "Program closed"
end
Converting password to number
The one problem arises because you don't consider the place of the particular characters when summing them up. The plus operator is commutative, that means
1 + 2 == 2 + 1
and hence summing up the ASCII values of "Paul" gives the same value as summing up the ASCII values of "luaP".
The other problem arises because a specific sum can be yielded in by several combinations of arguments. For example
3 + 6 == 4 + 5
so summing up the ASCII values of "Lisa" gives the same value as summing up the ASCII values of "Bart" (although I haven't proved that).
Decent string hash functions consider the location of where the characters are in the string by multiplying the sum so far with a constant. However, finding such a constant so that the result have a vanishing probability of collision is not easy.
I suggest you to not try your own solution but to use an existing hash function. There are several of them available from the internet. For example, the Fowler/Noll/Vo version 1 alternative (or FNV-1a for short) is available for 32, 64, and 128 bit hash values, and demonstrates what I mean above. It is simple and can be implemented without hassle.
Another point is that hashing alone is not very secure. For a password hash one usually wants that the reverse step, e.g. computing the unknown password from the known hash, is not possible with a reasonable effort. Hence there are hash functions out there that are developed with the demand to not being reversible, so-called cryptographic hashes. Well known candidates are md5 and the SHA family. Some of them are known to have weaknesses.
For passwords you should consider to use such secure hash functions.
Don't use MD5, it is broken, and if you can: avoid using SHA-1 too: https://www.schneier.com/blog/archives/2013/11/microsoft_retir.html
"Never roll your own crypto"
http://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own
If this is just for fun, or just for you and your friends or whatever, it's fun to learn how things work so doing your own crypto will be fine. Go ahead and use MD5 all you want. But if this is for something that is going on the internet, or for real users DO NOT make your own crypto algorithm.
EDIT: Just to add, look up scrypt as well!
Thanks for the replies.
This is for a game I am making which is for my own use with a view to letting other people download it and play it if they want.
I am limited by the programming language I am using (JustBasic) so I am trying to make it the best / most secure I can within the limits of JustBasic.