Encrypt a Password?

Meltdown

Registered User.
Local time
Today, 19:09
Joined
Feb 25, 2002
Messages
472
Hi all,

Does anyone know how to encrypt a password? , I don't mean just seeing asterisks as the user inputs data.

It doesn't seem very secure to me if I just hardcode my 'password' into my code, I was looking for something a bit more robust than that.

Thanks
 
In Access .mdb? I wouldn't store any secure data there as there is really no guarantees that it won't be extracted one way or other. You could use ULS; best to use built-in functionality whenever possible.

If this isn't to your liking, what I did (as I used a ODBC backend) was to have my users supply a password, which it immediately got hashed, added a salt and a operator in a deterministic manner, then re-hashed the string. The string was then stored in the ODBC backend. This also could be safely stored in a MDE because by then they'd have to decompile the algorithm to hash the input and they can't enter the hash itself because it'd just get hashed in something else and thus fail the comparison.

The only problem is that this requires that you have a solid understanding of proper cryptographic operations or you'll be just fooling yourself into a sense of false security.
 
It's difficult to do. You could get an encryption library (alot of free ones out there). They are typically written in C so you would have to compile them as a DLL or other callable library (or find one already compiled into a Windows library) and make a reference to them in your VB project.

One of my favorite methods is to multiply each character in the password by 2 before storing it and dividing them by 2 before displaying them (or the asterisks that represent them). This is typically enough to keep honest people honest. I'm not sure if this will work with non-US character sets, though (US character sets only use 7 bits for printable characters).
 
If I may be just a bit pedantic...

Encoding != Encrypting != Hash !!!

Encoding= replacing characters in a deterministic manner; shifting a letter to right is encoding, so is representing a string in binary form. This is security through obscurity. (IOW, no security at all!)

Encrypting= Using a key to generate semi-random message; basically a more complex encoding, but is very difficult to decode without the key (which isn't true for encoding).

Hashing= one-way encoding into a digest that cannot be easily reversed, so a hash will not tell you what the original message was, neither it can be ever decoded. You can only hash the identical copy and compare whether it was the same hash and thus conclude that it is in fact identical, but with just hash, you're SOL.

Most important of all: There is no such thing as a perfect security. Given infinite time and/or infinite computational power, anything can be broken, even hashes (see: rainbow tables). Thus, you have to decide how much complicated you want to get before it is sufficiently infeasible for any information valuable enough to be broken in a reasonable frame of time (e.g. if you have a method that guarantees that it will take 100 year of 24/7 computing to have a good probability of breaking, and that information is long past worthless, you can say it succeeds for your purpose. Or you could just stop with 10 year and leave at that.)

Like I said, you will have to have a good understanding of cryptographic operations to effectively implement anything even remotely secure. Or you could just use what Microsoft gave you with ULS and not worry about having to learn everything to know about cryptography.
 

Users who are viewing this thread

Back
Top Bottom