I am working on a login system that will be used in a UI and was wondering what is a good encryption algorithm? I have never worked with encryption before and this is not for work or school. So there are no requirments.
What type of encryption should I use? That's beginner friendly but solid at the same time! Hope that's enough info to answer my question.
Last edited by Annonymous; 06-26-2012 at 11:51 PM.
For a login system, encryption may not even be entirely what you need. You likely want to be using salted hashes. Then on top of that you could potentially use symmetric or even asymmetric encryption as well.
It's bad practice to store passwords in a database if that's what you had in mind. General rule is to only store the hash.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
OpenSSL give you this possibility with.Code:#include <openssl/evp.h>
Then you could use the function: PKCS5_PBKDF2_HMAC_SHA1() to hash a pwd:
So md will contain the password's hash..Code:SHA256_CTX context; unsigned char md[SHA256_DIGEST_LENGTH]; SHA256_Iinit(&context); SHA256_Update(&context, (unsigned char*)input, length); SHA256_Final(md, &context)
And for the salt:
where A_NUMBER is a number of your choiceCode:#include <openssl/rand.h> unsigned char salt[A_NUMBER]; int RAND_bytes(salt, A_NUMBER);
Yeah, that's exactly what I had in mind. I was going to encrypt them before storing them.Originally Posted by iMalc
So your saying I should use salted hashes for the passwords? So salted hashes it is then. Thanks iMalc.
Thanks polslinux!
I got the information I needed!
Last edited by Annonymous; 06-27-2012 at 01:25 AM.
O_o
Well, just in case you come back or for others trying on a similar problem:
The current recommended minimum length for a salt is 16 bytes; in practice it is better to use as much as possible without pushing beyond the yield of the algorithms employees.
The salt must not be an "nonce" from your database implementation (It is to easy to parallelize an attack given the documentation of such features.); use a cryptographically secure "PRNG" to create the salt.
The salt must be unique to a password.
Do not use any simple algorithm such as "MD5", "SHA", or "Blowfish" to generate the hash. Actually, it is better not to use a hash function at all; consider using modern algorithms designed to circumvent parallelism by trumping how such hardware behaves (I recall "scrypt" but may be thinking of "bcrypt".).
Do not attempt to code such an algorithm yourself.
Soma
Why ?
[naive] Won't it be more difficult to 'crack' without knowing what exactly was used (/created), even if worse theoritically ?[/naive]
A login system to log into what?
Like, if you're talking about say, a website, then using scrypt on passwords to be stored is great, but it is not so great if your users are sending you their passwords in the clear. The reason for not storing plain passwords then would be to protect your users in the event that your database is compromised and they reuse their passwords on other websites.
It is a general principle to assume that the attacker knows the system, because often, the attacker can find out. Besides, if you don't know what you're doing, then your snake oil may be so bad that not knowing the system wouldn't make things too difficult anyway.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Obscurity != SecurityWon't it be more difficult to 'crack' without knowing what exactly was used (/created), even if worse theoritically ?
When developing a modern security system you must assume that the attackers have both the implementation and algorithms and with that in mind still make the system expensive enough to attack that any attackers would rather spend their efforts elsewhere.
Systems that live on the web but no SSL almost always have that as an option.Like, if you're talking about say, a website, then using scrypt on passwords to be stored is great, but it is not so great if your users are sending you their passwords in the clear.
If the user doesn't have Javascript or similar available you can't play with other options.
Of course, that's a practical "fallback" and not a starting point.
Soma
I am creating it just to create it laserlight. Its just a project for my spare time. I finish one project and move on to the next. Something more challenging every time... something new!
I have a question though fo whoever can answer it; I have been hashing small strings, 20 chars or less. I was wondering, is sha1, a one way algorithm? I wanted to unhash the the data.
Besides the passwords that i want to encrypt, i also want to encrypt the data going to and from client and server. So unhashing the data will be a necessity!
Last edited by Annonymous; 07-04-2012 at 02:59 PM.
So i have figured the way to work with the hashed passwords is to store the hashes and use them as a reference point. If the newly entered password which is hashed in turn, matches the stored hash.
I am looking into AES encryption for the data.
Thanks for the help everyone.
