Was bored; Made an Encryption site.

[Objected]

I was bored a few days, and decided to make an encryption website. It wasn't hard at first, but then I wanted to add more and more features. It got fun, and now I want some advice on how I can improve it; and I would appreciate it if the comments would focus away from the design.

The following encryptions are supported:
-MD5
-SHA512
-SHA1
-Base64
-MySQL5's PASSWORD();

Here's the website link: Encryption / Decryption - Check your encrypted string against our database!

At the time of this post, the number of hashes are greatly increasing due to the fact that a password list (2 million passwords long) I came in possession of is being encrypted 5 times and inserted into the database.

When a user encrypts a string, if that string isn't already in the database, the string is added so that it may decrypted later.

The following features have been created:

-Encrypt & Decrypt (Based on database hashes)
-Login/Register
-View latest Encryptions

I'm aware that when logged in, you are given links to account settings and "your encryptions", which don't lead anywhere that work. I'm currently working on those.

Currently, the number of hashes stand at:

[MentaL]

[jMerliN]

Obtrusive javascript, poor segmentation of HTML template (multiple requests to non-cached PHP pages, and not caching them in divs and just showing/hiding), and server-side implementation (they can all be done in JavaScript, fairly easily). :(

[WizCoder]

Cool.

I just have to ask, do you know CSS because you could quickly whip up a more attractive design

would focus away from the design.

Yes I see that but in about 5 minutes you can have a pretty decent design.

Anyways cool

[s-p-n]

The following encryptions are supported:
-MD5
-SHA512
-SHA1
-Base64
-MySQL5's PASSWORD();

You realize none of these are encryption algorithms? In fact base64 is more similar to being an opposite of encryption, as rather than concealing data or trying to hide it, base64 makes it easier to move around/share data in such a way it can be easily decoded in just about any programming language. For example, base64 of an image can be used in an <img> tag in HTML so that you don't need a separate HTTP request for that image. Very useful stuff, but not useful for encryption....

The remaining 4 options are actually hashing algorithms. Hashes are created using uncertainties on purpose. Hash outputs (or results) can be created with a variable amount of inputs. For example, a hash of "xyz" may produce this hash "u592G0f" and "abc" may produce that same hash. It's impossible to tell if the original input was "xyz" or "abc" or some other random combination which happens to produce that hash. So, using hashing algorithms hoping to encrypt data and later expecting to decrypt the hash is simply a false hope- and for good reason. Hashes are often used for sensitive data we never want to retrieve or decrypt, but instead we just want to match. For example, if we store the last 4 digits of a credit card number, we never want to display that to the user. The purpose would be if the user can match the last 4 digits of the CC number, then we can verify the user's identity for some task they want to perform later. For security reasons, we never want a hacker to see the last 4 digits of any CC, so we store that data using a hash representation instead of the sensitive data. Keep in mind that a hash representation is great for matching data, but we may never retrieve the original data from a hash... In theory/hopefully/well it would be very, very hard, but possible with dictionary attacks.. it gets complicated.


Encryption is useful for messages or data we want to conceal into gibberish, ship across the world to the only other person who has the decryption engine, and they can process the data through that decryption algorithm and get our message. Again, very useful stuff, so good luck getting it ;)

[Objected]

...

Thanks for that clarification.

I'm currently in the process of adding more features to the website, and hopefully making the site faster in performance (I see that the site is taking a bit longer to get the number of hashes in the database and takes way more than enough time to encrypt a string and insert it).

Cool.

I just have to ask, do you know CSS because you could quickly whip up a more attractive design Yes I see that but in about 5 minutes you can have a pretty decent design.

Anyways cool

I do realize that the CSS isn't the best part of the site, but I needed something to work with the actual site. I decided to just do something pretty basic, and readable (isn't it?). If you have any suggestions to the design, feel free to share. I'll most likely replace the design with anything that looks better than this.

[WizCoder]

Thanks for that clarification.

I'm currently in the process of adding more features to the website, and hopefully making the site faster in performance (I see that the site is taking a bit longer to get the number of hashes in the database and takes way more than enough time to encrypt a string and insert it).



I do realize that the CSS isn't the best part of the site, but I needed something to work with the actual site. I decided to just do something pretty basic, and readable (isn't it?). If you have any suggestions to the design, feel free to share. I'll most likely replace the design with anything that looks better than this.

I find what's possibly slowing the performance of the website down could be the unnecessary amount of Jquery that is being used. Instead of using leaps of Client Sided Code you could make it load more faster if you sustained to server side scripting to output all the information.

As for the design I can't exactly show you but I have a cool sketch in mind in which I would have to present to you.

[Objected]

I find what's possibly slowing the performance of the website down could be the unnecessary amount of Jquery that is being used. Instead of using leaps of Client Sided Code you could make it load more faster if you sustained to server side scripting to output all the information.

What confuses me is that after I inserted the 12 million rows, the site began to be slow. ;-;

[TimeBomb]

What confuses me is that after I inserted the 12 million rows, the site began to be slow. ;-;

...12 million rows of what?

[Objected]

...12 million rows of what?

Password list. 2.5 million passwords.
Hashed every password in 5 ways -> MD5, Base64, SHA512, SHA1, PASSWORD();
Inserted every password.
12 million words.
12 million rows.
Yey.

[TimeBomb]

Password list. 2.5 million passwords.
Hashed every password in 5 ways -> MD5, Base64, SHA512, SHA1, PASSWORD();
Inserted every password.
12 million words.
12 million rows.
Yey.

What. The. Fuck.

Your reasoning for not using JS to hash passwords is...?

[Objected]

What. The. Fuck.

Your reasoning for not using JS to hash passwords is...?

Because I inserted them into a table. New passwords that people encrypt are inserted into tables as well, therefore I hash them server-sided and check if they're in the database; if they're not, I insert them.
Is there another way to accomplish this?

[TimeBomb]

Because I inserted them into a table. New passwords that people encrypt are inserted into tables as well, therefore I hash them server-sided and check if they're in the database; if they're not, I insert them.
Is there another way to accomplish this?

Oh, right, you allow people to save encryption into the database... although, it is a moderate security hazard to house unhashed/decrypted passwords in a database. Passwords should be hashed by the server and guarded by the user.
Maybe if you changed the site idea to something less specific, i.e. store your text rather than store your passwords, then this would all be slightly more sensible.

Next - don't house 2.5 million random passwords in a database. If you want people to be able to save their encrypted strings, then save the plain text and the types of encryptions that people wish to use. Then people can go to a "my encryptions list" page and the database will pull the plain text password and requested types of encryption, pass it to JS, and JS will render the encrypted/hashed password.

Or, you no, don't store anything in the database.

The site idea is simple; you're over-complicating it to the point where it is a moderate security hazard for anyone that registers. Changing the idea from store your passwords to store your text could help in this regard.
Storing 2.5 million generic passwords as well as storing the actual hash can heavily slow down your database - especially if you are not on a dedicated server and do not know how to professionally configure and manage a database.

[jMerliN]

A few things:

1. You don't need a separate table for each password type, even if you were insane enough store hashes. You just need one:

[password_plain, password_hash1, password_hash2, password_hash3, etc]

You just cut the # of rows in your DB by a factor of 5.

2. Performance is going to slow down because you need to index on password_plain, insertions on large tables with indices like that require maintenance of the tree structure used to store the nodes so that the index actually does something.

If you want it to be faster, you'd need to do significant caching and set up multiple servers so you can do reads on instances that won't be locked by a write, and so you can balance requests across them.


The easier solution, though, is to just do all of the hashes in JS on the client.

[Objected]

...

Thanks for the reply, but I think you may have gotten the wrong idea about the site.

Due to the fact that passwords are encrypted in MD5, SHA512, SHA1, and MySQL5's PASSWORD() function, I figured, "Hey, what if people want to crack passwords?", so I inserted the 2 million passwords. It does serve as a place to encrypt strings, regardless if they're passwords or not, but it can also serve as a place to attempt to decrypt passwords.

...

Thanks for the suggestion.

Every password had 5 rows each due to the fact that there was 5 encryptions. I'll take your advice and reduce it to one row - 5 columns.

Since the site seems a bit "dirty" to me, I'll most likely re-code it to and adapt it to the "one row - all 5 encryption types as columns". I never actually thought of that, and it's good to have that idea. Since there's only one server hosting this, and there will always be one server hosting this, this'll probably be the best I can do, unless I come up with a nice idea for optimization.

Thanks,
Jacob

[Gravious]

Generate the hash in JS and then do an asynchronous callback to the server side so that the password is displayed to the user without having to let him wait.

Also, if you're going to be storing people's passwords and allowing others to decrypt them not a lot of user are going to make use of this except for hashing other things than passwords.