How does encryption actually work?
I'm making a server in C# that accepts a login from a client and checks it against an account database. I had a look at AES/DES encryption and the only way I can see of implenting them is store the key on both the client and the server, so when the client logs in his username and password, it's encrypted with the key which can be decrypted on the server side with the same key.
My question is can't someone just decompile the cilent, get the key and then write their own AES decryption method and obtain a users password?
Am I just overthinking it and there really isn't a practical case where this might happen?
>>54312790
Who is this semen demon?
>>54312790
>My question is can't someone just decompile the cilent, get the key and then write their own AES decryption method and obtain a users password?
Use asymmetric encryption.
The best way to do this is to not store the real password on the server, instead of sending an encrypted password make a SHA512 and send that to the server instead. You won't have to worry about it being hacked.
>>54312790
Google "Asymmetrical encryption".
Instead of using the same key to both encrypt and decrypt, you can generate a key pair:
- one ("public") key is used to encrypt data.
- a different ("private") key is used to decrypt the data.
>>54312844
You still have to send the password tot he server.
You just don't have to store the password on the server.
Of course sending the password should be done encrypted.
So:
- server send client a public key
- client encrypts password with public key
- client send server encrypted password
- server decrypts password with private key
- server immediately performs SHA512 on decrypted password.
- server compares this SHA512 hash with stored SHA512 hash.
>>54312954
You wouldn't want to sha512 on the server side the password should be Sha512 before sending it to the server. Encryption would be totally optional at that point.
>>54312993
>don't encrypt hash on its way
>attackers can see hash on the way
>can send the same hash when impersonating you
tfw white girls have no ass
why procreate
>>54312790
>How does encryption actually work?
You take the bits and scramble+permute them really hard.
Scramble them hard enough and without knowing the exact scrambling pattern it's impossible to reconstruct the original.
>>54313037
Exactly.
>>54313059
fuck off nigger
>>54312790
>I'm making a server in C# that accepts a login from a client and checks it against an account database.
You want scrypt, no questions asked.
Take the user's password, pass it through scrypt, store the generated value instead of the plaintext password.
The client sends and server stores a hashed password, not plain text. Never plain text.
>>54312954
what's the point of using a SHA512 hash in this case?
>>54312844
So the server will only ever store a SHA512 hash in the database in this case right? Are there any cons to this approach?
>>54313103
>what's the point of using a SHA512 hash in this case?
In case the server gets hacked.
>>54313103
>So the server will only ever store a SHA512 hash in the database in this case right? Are there any cons to this approach?
Yes, plenty.
SHA512 is easy to compute (and therefore much easier to bruteforce), if unsalted it's vulnerable to rainbow table attacks and users with the same password will have the same hash (leaking information).
Look, I know you're a bit stupid since you're asking about crypto advice from /g/, so just use scrypt and don't try doing anything fancy yourself.
>>54313164
>Look, I know you're a bit stupid since you're asking about crypto advice from /g/, so just use scrypt and don't try doing anything fancy yourself.
haha surprisingly I got pretty good answers here. I had a look at SCrypt and it looks pretty good, I'll give it a go thanks
Salt your hashes, don't store the salt with the hashes, hash a large, non-round number of times on each password (e.g. 103826).
Computers are fast, but every additional time you hash will add up for attempts to brute force a stolen hash table. Your users won't notice a performance hit, you won't notice a performance hit, and the only ones who'll feel the hit is attackers.
>>54313059
They're still good for a pump n' dump
>>54313207
>don't store the salt with the hashes
Where are you going to store them instead? The cloud?
>>54313227
>what are separate databases on separate machines
>>54313207
Well you have to store the salt SOMEWHERE on the server, and if the server gets hacked, then what?
Hope it was localized to the db?
>>54313274
>Security through obscurity
If they have access to one database, it's a reasonable assumption that they'll have access to the other database.
>>54313274
>>54313288
>not storing every single bit of the password on a different DB running in different datacenters in different countries
lmao plebs
>>54313286
>>54313288
It very well could be that they managed to get both databases, but it's less likely than them getting access to just one. If the salts are in the same database as the hashes, then one getting compromised means the other getting compromised.
It would still be very consuming to brute force the hashes even with both, but why not go the extra few inches?
>>54313342
Your web app still needs to access both databases, so you've gained no security.
If somebody exploits your web app (and that is how they WILL get into your database) they still get access to both databases.
Splitting up your database only helps you against somebody seizing one database, but *NOT* the other. And that's just a non-issue in practice.
>>54313488
Security holes don't tend to be all-or-nothing. A security hole that exposes one database does not necessarily expose every database the app has access to. If you can mitigate the damage that can be done with a minor change in structure, why not?
>>54313575
>A security hole that exposes one database does not necessarily expose every database the app has access to.
But they're literally used for the same purpose, from the same function. They're completely identical databases except that one stores one half and the other stores the other half. If you're assuming you can access only one of them, you might as well make that assumption for the other based on symmetry alone.
You're unnecessarily overcomplicating things for the point of some religious belief in a mythical security hole that has no basis in reality. Just fuck off with your pseudoscientific security "advice" and security through obscurity.
>>54313694
>there is no way a database can be compromised than from the login function of the web app
"Security through obscurity" doesn't even apply here, at all.
> no one SOA's ITT
>>54312856
/thread
Also, please don't post porn on worksafe boards. Some of us actually browse at work.
>>54312790
Sauce on the image?
>>54313207
The salt is not any more secret than the hash is, and deserves no extra security. Check your local shadow file, the salt is right next to the hash, and nobody cares. Try to understand why you're applying techniques, rather than just blindly following them.
>Hash
Used to protect sysadmins and the like from just seeing your password, also protects from leaked password databases.
>Salt
Used to protect against rainbow tables, and other pre-compilation attacks.
>>54312790
Who is this dick pleaser?
Passwords shouldn't be hashed directly, key derivation functions like bcrypt or pbkdf2 should be used.
>>54313575
Then why don't you go follow >>54313304's advice?
Go on, store every bit separately if you're that paranoid. It won't help you, but whatever.
>>54314096
What performance hit do you take from looking up 2 values from 2 different databases?
What performance hit do you take from looking up every bit from across the world?
>>54314145
So the performance and complexity is somehow justified as long as you it's only a factor of 2?
At what arbitrary value do you place your cut-off? Why not split the password into 3 chunks instead of 2? Why not 4?
Justify this shit.
>>54314172
If we're going to play the "where does it end" game, why not store all of our data in one database? Hashed passwords, salts, profile info, etc.
Keeping the salts separate from the hashes is a tiny bit of difference from storing it in the same database, but with practical results. If just one database gets taken, e.g. the hashes, then even a stupid password like password1235 is safe from an offline attack. However, if the attacker gets a hold of both hash and salt, then any stupid password would come up in a matter of minutes. Of course, you should have password policies in place to prevent stupid passwords, but you can never count on a user to not be stupid.
>>54314272
>why not store all of our data in one database? Hashed passwords, salts, profile info, etc.
Except this is literally how it's done
>>54312790
http://e-x-a.org/stuff/articles/typing-a-e-s//
>>54314303
>database gets compromised
>emails taken
>names taken
>private messages taken
>transaction histories taken
>metadata taken
>credit card info taken
But at least the passwords are hashed, right? :^)
>>54314350
>storing credit card info
>>54314350
If database A gets compromised, there's no reason to assume the attackers won't also have access to database B.
You're gaining no actual isolation by splitting up the DBs because the web app still needs to store all of the database keys either way. So if you dumpconfig.phpyou have access to everything.
If you want isolation, then you actually need to isolate your subsystems: For example, have the authentication code running on a different system - when app A receives a login request, it sends the password to a daemon running on system B. This daemon then checks it against the stored hash and sends back true or false.
That way, if attackers breach into A, they still won't have access to the password database running on system B.
Notice how in this configuration, both passwords and hashes are still stored together - on system B.
The point is not separation of the databases, the point is separation of PRIVILEGE.
Most of the stuff in this thread is *moot* if you can't protect the password as you are typing it on the keyboard. Keyloggers, whether in your OS or your hardware (via DMA or EC), will nullify any attempt at security.
>>54314827
You don't hash your password to protect against keyloggers. You can never protect the individual password, you're protecting the whole list. A keylogger grabs only one guy's password, and that's okay.
>>54313089
What's better, scrypt or bcrypt?
>discussion about passwords
>people talk about SHA512
>People not aware Argon2 exists
>Pic related, it's this thread
>>54312954
>coming up with your own system
>not just using SSL
>>54315317
>being worked on for php7.2
when I can do
$var = argon2($var);
I'll use it
thx men
>>54315220
scrypt in theory, since it's resistant against attacks using specialized FPGAs etc. due to requiring a few megabytes of memory.
(bcrypt does not, which makes it easier to design specialized circuitry for)
>>54312790
Don't use encryption for that. Use a salted hash
>>54312807
>>54313776
>>54314015
Name is Tianna Gregory. Here's her instagram: https://www.instagram.com/_tiannag/
>>54316639
>her
>>54318102
>implying...?
>>54318246
>If "she" is a man, then I'm officially bisexual.
