What type of encryption systems are more secure?

[CODECRYPT]

Hello there, I have come up with ways to make web apps, programs more secure but I am not 100% sure if it only makes sense in my head or it is a good idea. My idea is that instead of using md5 encryption or any other encryption out there you create your own custom one with the encryption key built into the program. Could anyone help me to understand if this is a good idea and if not, why wouldn't it work? For example, If I had a built-in encryption system and someone hacked the database and got a users password but it was encrypted with custom encryption then there's no tools out there to crack it is my theory but I don't know if this makes any sense honestly.

 

[lexluthermiester]

Hello there, I have come up with ways to make web apps, programs more secure but I am not 100% sure if it only makes sense in my head or it is a good idea. My idea is that instead of using md5 encryption or any other encryption out there you create your own custom one with the encryption key built into the program. Could anyone help me to understand if this is a good idea and if not, why wouldn't it work? For example, If I had a built-in encryption system and someone hacked the database and got a users password but it was encrypted with custom encryption then there's no tools out there to crack it is my theory but I don't know if this makes any sense honestly.

To answer this question we need to know the purpose and use-case-scenario of the encryption. Different kinds of encryption work better at some things than others. The example you stated was a bit vague.

 

[CODECRYPT]

To answer this question we need to know the purpose and use-case-scenario of the encryption. Different kinds of encryption work better at some things than others. The example you stated was a bit vague.

For example, a PHP Login system that will encrypt the users unique id and password name email, etc. If it were to be an encryption build into the site would it be secure enough to ensure the encrypted data cannot be hacked and illegally decrypted? if that makes any sense lol. My idea is basically a custom encryption system that would be able to encrypt and data needed when every I create websites/apps, so that no one has the key to be able to decrypt but I'm not sure how realistically possible it is.

 

[micropage7]

Actually not 100% safe i prefer that made and widely used, if you build your own encription it means you need to make it from scratch, then about compability and bugs that may appear. So i think it's not worth building custom encryption from 0

 

[spectatorx]

First rule is to not make custom encryption because there is many ways to make it wrong. You need actually proper knowledge to make really safe, secure and correctly working encryption. Use already existing solutions as there is a lot of them available. Most popular now is bcrypt but more modern and even more secure is argon2 and i recommend this one. Only "downside" is that argon2 requires php in version 7.2/7.3 or above. For support of it in other other languages and frameworks you need to check their documentations. You didn't mention what languages and framerworks you are going to use so i tried to gave you as universal answer as possible. I'm mainly php/js dev myself.

MD5 is abandoned by webdevs since very, very long time as it has never been a decent encyption method. It's good you do not even consider it.

 

[Bill_Bright]

but it was encrypted with custom encryption then there's no tools out there to crack it is my theory but I don't know if this makes any sense honestly.

No it doesn't. It seems you assume your custom encryption would be more secure than governments and other organizations who have bottomless pockets and super computers to develop their encryption routines.

And if yours is "custom" not sure what the others would be. Generic? And it is important to understand how those "generic" encryption programs work. The data with the best encrption is typically encoded multiple times (asymmetrical encryption) using more than one unique key based not just on the encryption algorithms, but also on some user and/or hardware defined keys too.

First rule is to not make custom encryption because there is many ways to make it wrong. You need actually proper knowledge to make really safe, secure and correctly working encryption.

^^^This^^^ If you really want to get smart on this, go to school and become a cryptologist. Then come back and teach us because I doubt anyone here has been properly trained in it either.

 

[CODECRYPT]

I appreciate the advice I have only recently came up with the idea and thought it would be to easy in my head so if I asked I would understand which I now know how to go about this kind of thing so thanks for your knowledge.

 

[Bill_Bright]

and thought it would be to easy in my head

LOL I find there are lots of things that seem easy in my head, but not so much in reality. This is even more obvious as my body inches closer and closer to 70 years old!

 

[FordGT90Concept]

The risk of a custom algorithm is that it may have vulnerabilities you don't realize are there. They need peer review for obvious and not-so-obvious mistakes.

Don't use MD5, it's too weak by today's standards. SHA-512 is the minimum I'd use for passwords. One-way hashing in general is preferred for passwords because if the database is stolen, they can't just log in with what they stole. They have to turn those hashes back into a password the form accepts to gain access. This gives administrators time to notify users of the breach and time for users to change their passwords before their account is compromised.

If you need to be able to decrypt and encrypt, use AES. It's only as secure as the keys.

 

[Bill_Bright]

They need peer review for obvious and not-so-obvious mistakes.

I agree but that's not good enough. They need to be bombarded by supercomputers relentlessly on a continuous basis, looking for those "not-so-obvious" mistakes and vulnerabilities. That takes $ - or rather $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$...$$$$$$$$$$$.

 

[W1zzard]

Md5 is not encryption, it's hashing

If you put the key into your program, it's trivial to get it out using a hex editor and/or disassembler

Google:
Bcrypt
Security through obfuscation
Php password_hash

 

[moproblems99]

Hello there, I have come up with ways to make web apps, programs more secure but I am not 100% sure if it only makes sense in my head or it is a good idea. My idea is that instead of using md5 encryption or any other encryption out there you create your own custom one with the encryption key built into the program. Could anyone help me to understand if this is a good idea and if not, why wouldn't it work? For example, If I had a built-in encryption system and someone hacked the database and got a users password but it was encrypted with custom encryption then there's no tools out there to crack it is my theory but I don't know if this makes any sense honestly.

As others have already said, better off to go with a known product. Encryption sounds easy but it isn't.

Passwords should never be encrypted, only hashed.

Hashing hashes is not exactly beneficial.

 

[Bill_Bright]

Passwords should never be encrypted...

Why not? Encryption should not be the only method to "hide" passwords, but I see no reason why they cannot be encrypted, along with hashed. Encryption is still many times better than "in the clear".

 

[moproblems99]

As a rule of thumb, a site should not store a reversible password. Encrypted and then hashed is fine. I suppose I should have included it.

 

[Yukikaze]

Rule 1 of cryptography: You do not invent your own cryptography (especially if you consider MD5 an encryption).
Rule 2 of cryptography: See rule #1.
Rule 3 of cryptography: If you are an actual cryptography expert, and you've spent a few years developing a new encryption scheme, proving it is mathematically correct, and subjecting it to the scrutiny of other cryptography experts, and your scheme is accepted, then you may use that one instance of an encryption you designed.

Designing an encryption scheme is HARD. Even when using a well-known encryption scheme, it is possible to make easy-to-make mistakes that will render breaking it easy (or at least easier than it should be), especially in the realm of mis-using random numbers used as various inputs to encryption schemes. The history of security breaches is full of such misuse, and nearly every encryption scheme invented by people without cryptographic expertise (especially if the attacker possesses the encrypting software binary) can be broken, often trivially, by someone with a moderate knowledge of reverse engineering, or mathematics, or both.

 

[R-T-B]

MD5 is abandoned by webdevs since very, very long time as it has never been a decent encyption method. It's good you do not even consider it.

MD5 is a hash anyways, not an encryption.

This whole thread is a bad idea. Use well vetted precompiled code and update it until you understand this better.

Why not? Encryption should not be the only method to "hide" passwords, but I see no reason why they cannot be encrypted, along with hashed. Encryption is still many times better than "in the clear".

On transmission and in the database, sure. But it should never be reversible storage, was the primary point.

 

[lexluthermiester]

Passwords should never be encrypted, only hashed.

This is not only foolish and very unwise, but can get you sued and even jailed under certain circumstances.

 

[moproblems99]

This is not only foolish and very unwise, but can get you sued and even jailed under certain circumstances.

Do tell?

Plain text will get you sued. Hashed will not. By design, there is no need to encrypt a password before hashing it. Why? Because hashing is not reversible so you cannot extract the original password out of the hash. Sure you can encrypt it before hashing but it is not needed.

You should not only encrypt a password because it is bad practice to store an encrypted reversible password.

 

[lexluthermiester]

Plain text will get you sued. Hashed will not.

Oh yes it will and already has. Hashing can be very easily decoded. Encryption, even if only 64bit, is much more difficult. 512bit? Forget about it. Only quantum computers can do and even those need a lot of time(measured in centuries).

Why? Because hashing is not reversible so you cannot extract the original password out of the hash.

Absolutely you can, it's not difficult.

Sure you can encrypt it before hashing but it is not needed.

It seems clear that there is a misunderstanding of this process going on. A password should first be salted, then a hash generated from it, then encrypted in place and last encrypted again where it is stored. This is what is considered by most industry experts as the best practices methodology currently. Granted, I'm leaving a lot out of that process. Hashes are only generated as a method of verifying data integrity. They are not used to store actual data, generally. They can be used that way, but such is not very secure.

 

[R-T-B]

This is not only foolish and very unwise, but can get you sued and even jailed under certain circumstances.

Not really. I can think of several hash only password systems that exist and are quite safe... reversible passphrases not so much.

Most software solutions take passwords and hash in an with added "salt" and THEN encrypt it though.

already has. Hashing can be very easily decoded

No. That's the whole point of a hash (excluding perhaps, md5). I mean, yeah, technically cracking is feasible with a weak password on powerful hardware, but even that can be mitigated easily (usually via additional rounds or salts). Encryption can be used too, but doesn't have to be.

Hashing is generally harder to break than encryption given sufficient data to work with (pasword or data length)

 

[moproblems99]

Absolutely you can, it's not difficult.

No, you can't. What you are doing is bruteforcing the hash. You can do the same thing with any encryption method if you wanted to.

It seems clear that there is a misunderstanding of this process going on.

Ultimately I worded my response wrong. What I should have said is that you never store passwords in a database that can be reversed. At some point you have to hash it to make that work. If you encrypt and throw away the key you could never do the comparison later.

Only encrypting is better than plain text but it is still bad practice.

 

[lexluthermiester]

No, you can't. What you are doing is bruteforcing the hash. You can do the same thing with any encryption method if you wanted to.



Ultimately I worded my response wrong. What I should have said is that you never store passwords in a database that can be reversed. At some point you have to hash it to make that work. If you encrypt and throw away the key you could never do the comparison later.

Only encrypting is better than plain text but it is still bad practice.

I see what you're getting at. We're talking more-or-less about the same thing just using different terminology.