Any Security Analysts here?

[Tweezy]

I've just made my own encryption and decryption method for a really simple c# registration and login program.

 

My encryption works by taking the inputted password string and converting it to a character array which houses each character from the string. From there it converts it into a decimal number (Values of each character from ascii to decimal) and then multiplies it by a randomly generated salt number. This is how the hash it worked out. Then the password field in the database is the salt + hash.

 

I used this method as the password is never actually held in the database, making it pretty secure. The decryption works in the same way, except it grabs the salt from the database and then multiples that against the converted decimal value of the loginbox entered password. When the converted decimal value is multiplied by the salt, it returns the hash. The salt from the database is then added to the hash, resulting in a number.

 

If that number is equal to the password in the database, then the inputted password must be correct, if not then it is false.

 

This is my first ever go at running my own encryption and decryption method and i've never studied any form of security. How secure does it sound to you?

 

Thanks

[Nishok]

I did quite some research for this a while ago when creating a login system through PHP for websites, had a lot of support from back-end developers, too.

 

Using just a salt and a single hash isn't that great, because it can easily be forced out with a rainbow table attack on the database, which usually doesn't that that long to dehash (speaking of minutes to days, depending on the password used, too).

 

I would suggest hashing that hash at LEAST once again.

Also, the salt, the longer the better! (And as obvious as it may sound, don't show this salt to anyone, ever. lol)

 

Here is how I use it on one of the websites I made:

$password = MD5(MD5($password.$salt));

 

(Hint: VB4 uses this same way ^^)

 

Now you may ask, why only twice?

It is secure enough for any average website, and it isn't that resource hungry to calculate it (you can go with way more complex algorithms, but it may cause problems when hosting it on big websites with lots of users using the login system).

 

Here is an example what the code would do:

 

$salt = "t5N%>Tj#)1XQnrz(K-VY!S[XS,g*p&5wruksaTvI(9 F99pJUBm";

$password = "Some Random Password";

 

$password.$salt = "Some Random Passwordt5N%>Tj#)1XQnrz(K-VY!S[XS,g*p&5wruksaTvI(9 F99pJUBm"

Then the first MD5 hash becomes = "297b221070c26272917bbcc1670e3b28"

Then MD5 hash the previous one again = "84882ab129e63a99d64726d7004e2fc9"

 

Now, good luck with using the rainbow table on that.

 

 

For websites it is HIGHLY recommended to work with timed cookies (an even bigger pain in the arse to secure this baby) so people can't just steal your precious cookies to login to the website without even needing your password or needing to crack the hashes.

For programs you don't really need to do such a system (I don't even think I have seen a program that automatically logs you out after a certain amount of time).

 

 

Now, most of it is explained towards websites, but it is the same concept for any stand-alone programs, just different ways of hashing your stuff.

 

 

I hope it helped.

[Tweezy]

Cheers Nishok! I'm actually going to be changing the encryption into something a lot more complicated, going to need some time to work out all the maths and techniques, this is the basic idea:

 

The hashed password I'm using now is going to be the first hash, from there i'm going to be finding an nth prime number after the vale of the hash.

 

So, if the hash had a value of, lets say 600'000 and the salt's value was 200, the program would then find the 200th prime number after 600'000. This will then be stored and used for the second part of the hash.

 

That is the first part of the second hash. Next I will look at an enum class which houses all the characters of the alphabet and also symbols.

 

From that point I will then break the hash up into as many parts as the hash is long, so if the hash was 8 characters long, then it would be broken down like this:

 

| rE | rE | rE | rE | rE | rE | rE | rE | - 1 - | rE | rE | rE | rE | rE | rE | rE | rE |

1 ----2----3---4---5---6---7----8---(nC) --1 -- 2 --3---4---5--- 6---7---8

 

Where rE stands for RandomEnum (Picks a random character from the enum class). The above string just represents one character taken from the hash.

 

Where nC stands for nth character of the password hashed string.

 

So, if the password was, say 8 digits long then it would repeat that process above 8 times, resulting in a 136bit key - if my understanding is correct.

 

That's the idea! Going to start programming it tomorrow.

 

-- Edit --

 

Just updated my salt to a much, much larger number. The hashed password ended up being a minus number, login still worked fine.

 

Tried a rainbow table and a lookup table on my hash, it has no idea. Interesting.