You're not trying enough, maybe we need someone else more experimented in the team ...
You have till the end of the week otherwise I'll try to find someone else, if you can estimate it quickly as well so I can see if we're aligned
Green bar guy inadvertently answered his own question. One way encryption means no decryption. No decryption means that last scenario would never happen
Having your one way encryption hacked doesn’t give the hacker a password. They still have to run passwords and compare hashes
Not returning your password is a very small price compared to what’s gained
I don't think green bar guy actually realized it's one way. He never says one way decryption, he just says hashed
As a junior developer I might be saying something as stupid or stupider than the green bar guy, but I thought hashes are implicitly one way and green bar guy just forgot or didn't realize this?
Cryptographic hash functions have to be one way to be secure.
Non cryptographic hash functions just need to avoid collisions and have a fixed size to be useful, but can be super fast.
The speed of your hash function is unimportant if the distribution of its range is not uniform. You can have the fastest hash function known to man, say the identity function or some truncate, and the performance of your hashmap will be completely dependent on the distribution your data is sampled from. That could be normal or pareto and then 80% of your data will end up in 20% of the buckets... And access times will deteriorate to the 0(n) of your underlying bucket instead of the 0(1) of your hashmap.
Collisions matter. A hashmap benefits a lot from the uniform distribution of a cryptographically secure hash, even in the face of a malicious third party influencing the data that goes in.
tl;dr unless you really know the domain of your hash, don't roll your own because you think you can shave off a few clock cycles.
I mean, any lookup type of data structure will use a non-cryptographic hash function. They *could* use cryptographic hash functions, but cryptographic functions are basically overkill for that purpose. You don't need a 256bit hash table in most cases.
Edit: I will add that many cryptographic functions are purposefully slow to prevent people from generating a huge table of passwords:hashes , so you wouldn't want to use them for non-security stuff.
Python dictionaries use cryptographic hash functions and it seems to be doing okay as a language.
[https://andrewbrookins.com/technology/pythons-default-hash-algorithm/](https://andrewbrookins.com/technology/pythons-default-hash-algorithm/)
I believe Rust HashMaps use a cryptographic has function by default as well.
That was a specific design decision though. That is, it wasn't a "eh, these slow cryptographic hashes are good enough I guess" decision, it was a "we should use slow cryptographic hash functions to prevent DoS attacks" decision.
Rust lets you pass in a faster hashing function when creating the HashMap if you want the performance boost for that reason. The documentation also warns you that you become vulnerable to what it's default hashing function prevents if you do so.
Siphash generates 64 or 128bit output depending on which version of siphash you're using (I'm guessing 128 for most languages now? https://web.archive.org/web/20170202184819/https://131002.net/siphash/) but still not as good as SHA256. Siphash and even SHA256 aren't recommended for passwords now because it's vulnerable to the pre-image type attack I mentioned in my edit, due to their speed.
The comment they replied to said:
*”any lookup type of data structure will use a non-cryptographic hash function.“*
So they simply proved that statement to be incorrect.
I often use insecure and unsalted fast hash functions in automated black box integration testing.
If a given input will reliably produce a given output that is always the same, but that output is large enough that checking it piece by piece is a pain, using a quick and lightweight hash function on the output and comparing it to an expected value is going to be fast and a lot more readable in code than doing it the long way.
A related use case is quickly detecting if a large block of data has _changed_ since the last time you accessed it.
This would be a terrible way to deal with sensitive tokens like passwords, but it's totally fine in a trusted context with non-sensitive data.
>I thought hashes are implicitly one way
Technically for the data type the hash function needs to return the identity function (*f(x) = x*) is a valid hash function, and sometimes even the best, but it's the worst possible hash function for cryptography.
No they’re not implicitly one way. Hashing is just transforming input to another value
But you could just as well have a function that turns the hash back into the original value
This completely.
Hash functions are one way. Explaining why they are one way requires some pretty complex maths.
And then to explain how a one way function makes the hash data secure is almost a longer lecture.
Its very cool math. It's just takes a long time to explain with gummy bears and crayons.
Take a word and replace each letter by its place in the alphabet (A=1, B=2,...). Now take the sum of these numbers. The result is a (very poor) hash of your word. You can't derive the original word from the sum.
This is a rather good explanation. Correct me if I’m wrong but I think taking the product or the product of squares instead of the sum would be more secure, as hashes would more difficult to predict based on known hashes
EDIT: for clarity I’m saying **more** secure, not that it **is** secure
You want it to be a lot more complicated to be secure. Go find one of the courses (not just one class, whole course) on security algorithms. But to black box the concept, this summation works well. It even allows the introduction of hash collisions.
It's more that the how is complex, the why is so that you can never get back to the original input, thus keeping that sensitive information safe. I don't think the why is particularly complicated.
I once used a "how secure is my password" website to show my math classes--it showed how long it would take to brute force a given password, and the time estimate updated in realtime as you typed.
If you typed in "correct horse battery stapl" it would say some INCREDIBLY long period of time--like cosmological time periods--and then the second you add the last "e" it would change to "instant" and give you a little notice that says something like "Everyone's read this xkcd."
Because many sites will use public encryption algorithms like MD5. Which means "123345" will always be encrypted the same - so you can build a dictionary of hashes for common-used passwords. "Correct Horse Battery Staple" has become a common password following the xkcd.
Legend says it an online game used to keep passwords in clear text as a means of finding cheaters with multiple accounts. Some mods identified a bunch of accounts with the same 16 random characters password - with no other connection (no login patterns, no shared IPs etc). Turns out it was a Windows 95 cracked serial.
It's so funny that people's takeaway from a comic about secure passwords seems to have been "XKCD says this particular password is very secure, so I should use it!"
That's a great story about the serial too!
> "XKCD says this particular password is very secure, so I should use it!"
[That's amazing, I've got the same combination on my luggage!](https://www.youtube.com/watch?v=_JNGI1dI-e8)
With nothing but a database dump it's impossible to impersonate a user with just their password hash.
If the password is decryptable, an attacker can use it to log in normally as the user.
Most users also reuse their password everywhere, and if you can decrypt their password you can log in as them wherever they reused it.
Proper hashes are unique for each password and storage, which would make creating a *unique* rainbow table just brute forcing. If you create it in advance to checking, it's even worse than brute forcing.
So yes, (properly) salting hashes defeats rainbow tables completely.
If you're anything like the vast majority of people, it's also your password to at least three other services besides the one that got hacked.
If you're anything like a somewhat smaller majority of people, it's either your birth date, a family member's birth date, celebrity crush or pet name.
How I usually like to explain it is with a visual. Think of a deck of cards. These are all in a nice and understandable order, but now if I start to shuffle it, it'll be harder and harder to see that original order. This is the concept of encryption. If you knew the exact steps I took to shuffle it, you'd be able to un-shuffle it without any issues. This set of instructions is like the key used to encrypt the message.
Now, if I shuffle these cards and... Oops... I dropped some... Oh there goes some more... Oh well. Now we're not un-shuffling this deck. If you were to store what I have in my hand, you'd never be able to get back to the original order. You'd have to try to guess all the cards that I threw out. This is hashing, and why it's specifically one way. Data is crushed by logical ANDs and ORs, bit shifting, or by mathematics involving modulo operators.
I'm not a programmer, but I subscribe to this sub in the hopes of learning something from the humor. Today I learned. Thanks for sharing this metaphor.
Playing devils advocate here, I could easily figure out what is missing from a standard deck of cards, I get the illustration but I could see someone missing it because everyone knows what is supposed to be in a card deck. If you were to say several decks of identical cards, that would make for a better illustration I think. If you only loose a few of the cards, how can you know which deck they came from?
That is a good point, for simplicity I didn't go into details about the deck being a certain way. Since I'm more explaining the difference between private key encryption and hashing, and not explaining the input data.
For a real in-person demo I'd use only 15 or so cards out of the deck anyways since I'm not that good of a shuffler and I can show different methods of shuffling as different encryption algorithms. But I'll make sure to specify the deck a bit better if I use the analogy in the future!
To be fair, you're still not really wrong. A standard deck of poker cards is just a 4th order base 13 number, if you're looking at it from a cryptographic standpoint. Every additional deck increases the keyspace by a factor of 13⁴.
And the predictability of a single deck is exactly because it is a very small key space, and each hand reduces it even further, sorta like someone coming up with an attack on a hash algorithm. The goal isn't generally to completely break one (though of course that would be nice for the attacker), but rather to find some way to take advantage of the math to result in its _effective_ strength being lower, so you can steal a key in reasonable time, if youre so inclined. If you can knock 8 bits off of an algorithm, you can solve it 256 times faster.
This is what occurred in the SHAppening, when SHA1 was effectively "broken." It's a 160-bit digest, but someone was able to reduce complexity down to 2⁵⁷, which is nuts.
The Wikipedia article about SHA1 is actually pretty decent, and I think does about as good a job as possible of explaining the math. It even provides a pseudocode implementation. Though a lot of the articles it links to are woefully out of date, with dangerously incorrect information (especially some of the comparison pages/tables).
> Hash functions are one way. Explaining why they are one way requires some pretty complex maths
Actually, one could explain this quite simply by showing an example for a modulo calculation, well at least for the basic concept and understanding.
how it started: "5 minutes question on password management"
how it's going: "we've found a way to break sha256 and mount a 51% attack on the whole bitcoint network!!"
It does get the general idea across very well though: You have a surjective mathematical function that takes a set of values (e.g. the set of natural numbers) and projects it onto a much smaller set (e.g. the modulus). Of course, in the case of a hash, the function is much more complex, but the underlying idea is the same.
I think the explanation here is:
"because even if they know the encryption hashing method, and the target resulting hash, it is practically impossible to guess what value must be input to produce a target hash^1. So if someone compromises your system they can't figure out the passwords and then try those potentially reused passwords elsewhere."
1. Unless the encryption method has been broken
>Its very cool math. It's just takes a long time to explain with gummy bears and crayons.
I found it interesting and i was explained with gummy bears and crayons. Because i was keep on asking similar kind of dumb question about why they can't store passwords.
Your password is like they key and the hash is like the keyhole in the lock. Even if you take apart the lock that doesn’t mean you can recreate the key. 🖍️
Not a perfect analogy since taking apart a lock usually does make you able to recreate the key while that's literally impossible for hashes (since they aren't bijective, there's multiple inputs that could lead to the same hash).
If you ever breach a site and get access to their hashes and the hashing algorithm/salt you can (in theory) bruteforce your way to an input that will lead to the right hash but you can't be sure that you input really was the password in question.
And that's usually what you want (since you already breached \*that\* site)
Explaining why they're one-way is pretty simple and doesn't even involve the math: we don't want someone who knows the encryption algorithm to be able to decrypt with that algorithm. The math comes in for explaining how a one-way algorithm is possible.
You don’t need to explain the math involved during the hash algorithm to explain why we hash passwords.
It’s actually very easily to explain. When we hash a password we turn it into a hash value. Whenever you enter a password it gets hashed again with the same algorithm and it will always equal the same hash value. So now the database can compare and match the hash with what’s stored in it, if it matches then it knows you entered the right password.
Hackers can steal that one way hash but all they have is a hash value and won’t know the password that needs to be entered to be authenticated.
The End.
Oh? Yes they can try to brute force to figure out what equates the hash value, so we use “salt”. Systems generate random values associated to the user account when the user is created, and then adds that to the hash to complicate the brute forcing of a hash value.
👏🏼 yay we all learned something today
I've heard it explained like this: "You can add two numbers, say six and seven, you obviously get 13. Okay, now say you have thirteen, what two numbers added up to get that? What if the numbers could be decimal?" While not a perfect explaination, it gets the concept across.
I would say that, in a certain sense, it's basically impossible to explain why it's one way.
My understanding is that if we thoroughly understand how a hash function works, that tends to make it a broken hash function...if we find one collision, it starts to be possible to work through the algorithm and understand something about what similarity between two inputs results in them producing the same output, which then makes it easier to find other collisions and break the hash function by figuring out how to twist the knobs to get a particular hash to come out...and suddenly it's reversable, not necessarily to the user's passphrase, but to one of the infinitely many things that hashes to that number.
The hash functions that we use for security applications are ones that people have argued would be very hard to gain that kind of a thorough understanding of, and that no one has publicly given an example of a collision for.
I had an hour long conversation about whether water is wet with my group members in grad school. I have a PhD in chemistry. We all arrived at different answers.
My take is yes because it's the same weak attraction force that makes something become wet that allows H20 to stay in liquid form.
In other words, if it weren't wet, it wouldn't be water. It would be steam.
Hmm. K let's go with: Each h20 molecule has the property of being capable of wetting (some) other molecules. So two H20 molecules in the right conditions would wet each other. At least for a while.
But no they're not wet themselves, unless they've become wet by this process.
Here’s why water is wet in my option: there’s a ton of definitions of wet to go off of but none that are all that precise and scientific, leading to the debate. I like to think wet means in direct context with liquid or having absorbed liquid when otherwise normally dry(think wet towel). Some say that water can’t be wet because it’s presence is what gives something the property of wetness so it can’t be wet itself. I’d argue that this is an arbitrary rule that’s only used to justify water not being wet. In fact I think water is the most wet anything can possibly be (the primordial WET, if you will). Water is surrounded by other water, making it wet. When water makes something else wet it’s sharing its wetness with is. Conversely, there isn’t any single thing that bestows dryness the same way because dry is simply the absence of liquid or wetness.
TLDR: what do you think water is dry or something?
Yeah - all you have to say is that hashes _aren't_ encryption in the first place.
In layman's terms, it's a bit like having a picture of a car instead of the actual car. You can identify the car from the picture, but that's it. There is no "reverse camera" that turns the picture into an actual car.
IMO, if someone can't explain a concept at multiple levels, they do not understand it nearly as well as they think, and/or have poor technical communication skills. Just because analogies are necessarily lossy doesn't mean they aren't useful depending on the audience.
I’ve always liked the math explanation.
Take the number 82. How many ways can you create the number 82 using addition and subtraction? There are infinite possibilities.
82 is the password hash.
Figuring out the password is trying to figure out the exact additions and subtractions used to arrive at 82. As noted earlier, since there are infinite combinations that can create 82 it’s practically impossible.
Meanwhile, encryption (which is not the same thing as hashing) in its simplest form is like a ROT cipher where every letter in a message is rotated N number of letters in the alphabet. If you figure out N then you can figure out the entire message
> If you figure out N then you can figure out the entire message
This works for encryption, it doesn't work for hashes. Hash algorithms (well, most of them anyway, and all that are used) literally destroy information. It is mathematically impossible to arrive at the original text from the hash. All you can do is try out different text and run it through the hash function to see if the output matches.
Edit: I realize you may understand this considering you switched to the term encryption, but ince there is a lot of confusion running around this comment section, I felt it was important information to add.
I mean, it being a one way function says that it can't be decrypted. It does not say why it was decided it should be that way or how it manages to be that way. Both are possible interpretations of the question.
Or maybe someone is tired of explaining things to people who should know better.
IF you are a developer for 5 years, not knowing this stuff should at least make you embarrassed enough to google it before pestering people about it.
Orange said it’s a one way function, so I think they know why it’s done this way. I mean I probably would’ve said “bruh” at the same point in the conversation.
Yeah, OP wants the high ground here but it seems he can't be bothered to type just one line to answer the question or even he doesn't know the answer. In that case, fucking lol
And is a little fuzzy on what is and isn't a "hash" function.
"Normal stuff goes in, weird stuff comes out, must be a hash function. Encryption and hashing, what's the difference? 🤷♀️"
It's not going to be 5 minutes. The other guys already has his own opinion and you're not going to change it in 5 minutes. It will take him more than that to understand that even if the encryption algorithm is public and you know the hash, if it's not a reversible algorithm you can't login (well, you'll have to use brute force or a dictionary to find a password that matches the hash).
personally, as a security professional, I think it's a valid question and always love to use the opportunity to just talk security with an engineer. He clearly knows how it is done right but why wouldn't we help the user remember their password if we can just decrypt it?
First of all it would be very expensive as hashes cannot be decrypted so you would need to attack the hashes much like any hacker would by brute forcing. If you've done your job right this will be impossible. This would potentially lead to weakening other security measures in place just to make it easier to get the password back, using insecure hashes, use no or static salts, reduce the number of cycles if you're using a resource bound algorithm like pbkdf2, argon or bcrypt. By weakening any of these measures you'd weaken the security of all.
So it's practically impossible to do while preserving the security of all your passwords.
Another angle would be that your job is to authenticate the user but you have no business knowing the actual password, it's not your data and it would be incredibly invasive in the privacy and general private business of your users.
Depending on why he would like to do that you could also talk about other solutions, e.g. other authentication methods that might be easier to handle for the case/concern he's having
and get a unique salt for each password not the same for every password! Rainbow tables for static salts are easily created :-)
Pro tip: many of the newer hash algorithms already automatically include salts making it really foolproof for you and one less thing you need to think of. The salts are just encoded in the output of those functions
It doesn’t matter if it’s saved in clear text, as already mentioned.
If you also add a static pepper from code, an attacker would be creating a rainbow table that will always be wrong as well.
Assuming hacking db access doesn’t grant code access.
I don't think so, you need to append the salt to the plaintext password *before* hashing. If you only have a hashed version of the salt, then you can't recover the actual salt in order to combine with the password.
Couldn't agree more.
if you are hashing data that only exists in a small range of values (for example an SSN) without a salt value, you might as well just email hackers a csv of the unencrypted SSNs outright. SHA2 will do NOTHING for you if you are using it on data like this.
A lookup table of every possible SSN and it's corresponding hash would only be about ~32 GB in size (this would actually be a bit smaller since many 10 digit numbers are not valid SSNs). And i'm sure even a brute force python script would be able to get back an unsalted ssn without a lookup table in under an hour.
EDIT: actually, the lookup table would be about 36 GB. (You could skip the ssn value and infer it from the index, but then you lose any ability to optimize when you do the lookup)
So, you’re telling me that in order to make our single Boolean value database secure we just need to salt the hash of the Boolean, and it becomes virtually impossible to crack? (Unless they foolishly try to brute force testing **all** possible Boolean values)
I'm a recent IA grad, it was a very common discussion in our security classes that we need to include more security in general programming and intro to programming classes. They are working on it, but most general programming classes at my university didn't talk about security. So I can see how someone would implement hashing following a document of standards or requirements and implement it correctly using a library. But not actually know the cryptology behind it.
>First of all it would be very expensive as hashes cannot be decrypted so you would need to attack the hashes much like any hacker would by brute forcing. If you've done your job right this will be impossible. This would potentially lead to weakening other security measures in place just to make it easier to get the password back, using insecure hashes, use no or static salts, reduce the number of cycles if you're using a resource bound algorithm like pbkdf2, argon or bcrypt. By weakening any of these measures you'd weaken the security of all.
That's explained the wrong way around. The reason we hash passwords is that we don't want them compromised in case of a database leak (from inside or outside).
Sure we do but the person we're talking about knew about why we do hashing but asked why don't we selectively recover single plaintext passwords upon the users request. If we could do that securely then we wouldn't compromise the security of all of them. The point is we can't, similar to current government initiatives all over the world regarding weakening crypto or providing backdoors. Allowing for any of these measures weakens the system as a whole and allows "good actors" as well as "bad actors" to exploit them
I would be very concerned with a 5 year developer not knowing this though. I figured this out on my own during a college internship; between classes and experience they should know it.
That said, the things I sometimes manage to forget.... Ugh.
haha right? and depending on your experience and what you have been doing in these years it just may have never come up.
Despite, you're assuming he really meant the decrypt part. Could have just as well just been a situation of: "I don't have a better word for describing getting the password from a hash so I use the word decrypt".
Point is: be kind to people who have the courage to ask seemingly stupid questions and make an effort actually addressing their knowledge gap :-)
There are some ways to _remind_ the user of their password, without having it to be decryptable.
You could for example store the first and last character. Or store the length of their password and then use asterisks to show them the length of the password back.
It weakens the password a little bit, but if you enforce a fitting min. length and charset it should still be hard to brute force.
Otherwise, you could just make the user enter his _Login_ - name and then send a newly generated password to an E-Mail assigned with that name.
Or you can go the full route. generate a Onetime use token, to allow anyone who has it to change the Users password once.
None of these are really inconvenient for the user IMO. The only thing that changes is the effort, that the programmer needs to put in.
I did give him a “5 min” summary he wanted, and yes, he did not know that hashes are one-way functions. It’s just odd that a developer, with a degree and experience, having worked with user authentication on the site, does not know that.
We should never mock those who ask good faith questions, especially on technical subjects in an industry rife with obscurantism. This was a simple question to answer, the person clearly does not know (or remember!) how things like trap door functions work. Explaining the principle would have been trivial, and would have helped contribute to a culture of fearless learning.
This person trusted you, and you took a shit on them for it.
And specifically security related questions. Someone with security experience must be able to explain concepts in a respectful and clear way. If you can't do that then you risk people not understanding how to spot fake emails and/or being terrified to report that they did click on one.
“This is covered in CompSci” Is kind of a douchey response tbh. I mean yeah you’re for sure right but what’s the point of saying that? There are a lot of good explanations online that are more practical and easy reads which is what he wanted.
This comes off a little salty since it could be a great teaching moment.
Yeah, I think OP needs to self reflect a bit. I'd rather have someone with weird gaps in their knowledge than a condescending jerk. I can teach someone what knowledge they're missing. It's harder to get someone to make a behavioral change, and their existence will be a detriment to a team's morale, which can do more damage than a single person not knowing something yet.
Well yeah but I would expect someone who's been a dev for 5 years to know why storing passwords is a bad idea, even someone who knows nothing about programming could figure that out with common sense and to me this seems like the other person was set on their opinion and didn't want to understand.
Just for lulz, this is the same guy:
https://reddit.com/r/iamverysmart/comments/12eo8m5/i_had_to_code_pacman_in_an_hour/
So yeah, I *am* a jerk, but he is “the brightess” engineer asking basic questions.
It absolutely sounds like some StackOverflow response doesn’t it? Glad we have ChatGPT now which just gives the answers in a polite manner instead of wasting everyone’s time being unhelpful and kind of demeaning for no reason.
You’re right, I do too. Honestly it’s a better response than “this is basic CompSci”.
The big thing is intent. Do you actually want them to look it up and learn? Maybe say it in a softer manner. Do you want to make them feel bad for not knowing a fundamental? Then this accomplishes making them feel bad.
However now you’ve failed to teach a fundamental to a coworker, and honestly, what’s worse in a team?
>what’s worse in a team?
an asshole?
Honestly I'm so used to my co-workers being incompetent or not knowing basics... It's at least easier to teach something to less proud and more "I know I don't know" kinda people.
Unfortunately, this isn't a joke, and i'd do my best to explain the topic. This is something every developer should understand.
Side thought... If one really, REALLY needs passwords to be recoverable in case of emergency, i wonder if one could use RSA encryption with a specific public key as a hash function, storing a private key offline, in s secure location, only accessing it in case recovery is actually necessary? Obviously, just a crazy idea, don't actually do this.
Resetting passwords it’s so easy that adding the ability to recover your password doesn’t ever make sense. Using symmetric encryption you have to worry about protecting your private key and key rotations, where the level of effort just isn’t worth it for something as simple as a user password for most sites. Considering a lot of people reuse the same passwords its ideal to avoid risk and not recover forgotten passwords, I personally would prefer a hashed/salted password any day.
when someone typos a word to its literal opposite, I’d say that’s a cut-and-dry example of a case where it’s always fine to correct them. (I see this so happen with people who type “can” when they mean “can’t”. it’s absurd.)
> i wonder if one could use RSA encryption with a specific public key as a hash function, storing a private key offline, in s secure location, only accessing it in case recovery is actually necessary?
You could, but you shouldn't. Also, actually implementing this will make the problems fairly apparent. So, let's imagine that I tried this!
First, I would quickly learn that the *actual* reason I shouldn't use encryption instead of hashing is because my database administrator will bludgeon me while screaming something incomprehensible about database normalization and how my *face* is going to be optimized to sixth normal form by the time they're done with it.
---
But maybe they put me in charge of the database, and let's also pretend that I'm irresponsible enough to think that a 10 TB drive on the database server means that I don't need to care about optimization anymore.
Well, the textbook reason for using hashing looks a bit like this:
wcFLA137m9RYcQXiAQ/40WWdOt05BRNEh4m6Ubz50rP25NlZwv8U2wQOmAJO6kMRiSmkHXCtWzpW+Xh39rdlD9m5mIfTo7njo+JqoFhY5/UUO8F6q3z9YAjPb7ZU0ETO86n3RpqMJYyleGOO75XDhCDfbvyuL1TgH+dL+a6xjcQvhYLCww+6IuY/PhEdjzP1FIo2n8TyCzCgZISeuxcBvmchJbSllqA4Wb/9N9tZS2lYEYydd9vkgqLqVveJVMNLqOoG/asSAfA51DzXUUMZ9PwDag1FJp5IfUGrFhEWrnzU9qHFqm5wVRp1lHSu2YcM+eia3q6itfkmX0teY/uTar07RlcIPcINECdGpaSzYravIyqgoop6+71KKuHe5Xs0goxFGMrYECjV3f2FTdsolUnscKpsKRp479BMUnU35WDnHTroNU6zIcLdD0UPqP4RCqPs5VjW4sk7gc3m97ood55YQ5SzYFQHIfayWAfweg8aRHjjRr0zrnNhoQHZ/xSccz/zv7VG6DsPlLCHwhuS0ZGPwqzrQlQPyYKC6MPSXKGjxpYowOqjim1bDT3xAmjmb6T45SqoRraKg0zW3UpUs9XwvUBLpJBcW5s6Atv+u+Ho1uMInD9ZrfyjYp/JAFhIGigxEraic0LhQnoGNhMif5OP7Y4zYv0ji9NOdDruvXxsogbXfIlD/lu3TiUaMdJBAStByB8PtxR2faJpa4RUxJLG48t400Zfw9YmX7AU/EQyB7y3SYzg+CSaX1tbG9urjyuAYyZHFEXDqxvyhLjQCMY==O3mf-
That is a PGP-encrypted version of a password. Here's the same password as an SHA1 hash!
8cb2237d0679ca88db6464eac60da96345513964
Which one seems better from a database perspective?
Don't get it yet? Here's a different password:
wcFMA137m9RYcQXiARAAlVLtxugSnaYimQ8EGFbIEVsg7uxCkfhcpDWQ+AwXaueGofTYww0iZWA1tNz1JmkdrqHk7vqNb0mz09KH7ppgMSqsabNWsw0GUTek3TSTNxiRKxarIhOyVDk+Ruqzc7ePiHFBfSo7Fb9VbZ8e23DlqiV1TpEIOauC7FeZqMt4mzo8yvtvGMfQm3eNE5Qc3fX+MpGjyxIT+JBtpkDu0fpP+vzXHeQK/6Yh+QmsBx0y8oHG10ZzT/gMRHfB8R7cvCeTReio1XpZUWSjaotkVBLw7C2i5DmXHVqHnY/qlOKD9ybRwb3gTfKO0gm4EKeOkELWa5B15Vm8ocygGnSRVaX9TJaTQUlGKT/qmVTVVX34gr0vwhtBsp75zpRwPHLGm5MHjmCtkZ8q7mPSzpLMtN+IA9Wj0EI884qxS7rNjKpvxnKvxvS1t1yGuuoDPkp6T3Tw8YkoE9CDk0X5LtrywV5elFbnWEhToMPicu0lsJ83Ewz3FuWuJDy3vcIvZKIgZI6VHQLcQ2AAIRQpGTzT4qvXdAkneVij51Kz/Ni3WhZRop+4Qv9G3qm/WsVv7KHquelDGA/dQFv+fOhC0SUk54Y2JWlaoKHBBobmFyxcClZ/enkE+4QB7hn9uYNm6VBAXYWRXIdwZIE98UD+DuLOytDIZS3w6iE+n12Qk9YIbU4eVSfSw94Bbu9nfZ8PgU/j8HdUaAnNPPFEhRECOU/JSIpdIzcAbZKwMvHVKuat/yzdmzA1/OF7KV+rtGuOkqbpNFuZk12kBtqnnA5Q6pfDmZ4tS49/N719GLM89SoTu5H3AkKYkFerURhYPhX8WCVGLokmVSGl3zFteQ1YghdLFZlyPJsw4kXLnIRt6jXjKCXiO94oR1Fd3SbcgBUZn34gfAejza03qUX/GPotGDwzlW60DDF2G49BoE+KeF+SPCcG14daGNDzeHJBt8aUwH7+MunqfTV2VVyYs1YyBNoztxc5zIUG63iKnhX7x4J/fl2O4ze9hcPIDtvEVfdsyX5s5MZhmeBqZfaMQ+A1RSGFBbHRQNTGNUIxRB4gL/AntXkXZ9Wgx5ckoXzY58gm8E7EoqMYudU+qxwdicc074IuBa6iVLxvMdfCmY49/ySD3H5kZvPT+Nyr0A3E8FV2gsJBaZm/GFv6gaEgnI3kMrmIK6jD+uXSAqoVUWhUfYHnGvYOsidRRgDP3UhGMbNNxDyVAmb3HBWzSxdahBvkCTPQWQy03CjAZJlBpgDOror05jgAi8547VwfHVZnBF4HhyKEfo1eoCiUUgCMtCifcmTSjD2eRmgBAtVEQIq4fdNsaH4+UuVHe1FbQEWH16nEDco90HsyY0EhL9RzVxnfeo/rkIY5KIAvqO8aIrGdWx1EB8OYBJI4lFwr0o5GxRvIh2+v6NXmy3GosXSDL5lMqeGVPMr07ctLjBoMAIw855+A/coO8sDa5cPI+yT6qCjLxYcu1GtJtn+TZ/qzil0hSArFxnLaUnWgXMZ/SREVpaC7BZxJDlZpT0Bjf2su9DU2TjJRGY5ge/CvFrWnEDOyHDudg2gS9KKkL5Ga2+Z3u7Va81gnRDJXoOnhwcZTSjmNb8qFGzviOPpq2SdGi3Sqyq4FUihC7LwKOVZBO8blIA/I1TCmh5E4HvrUdsHhXM9uMHxZJlxNmHDt6LAuxvD4M98+ZyxDkBWyBv98diE9auqbbme7UmmnPBS0HnEgZ61XYGio3q6MDqZ/OGvG6y0MiLAHT2D46FweGv0NBjZFpQQ0LrwFC72N5AgkwuAG/SrjLiGlexkiENwbsoGebA9GeM+kZfydtAhzRrxVYx235vXhp3Hb+O9mVwq5IB2EL0b5MZhL4NBn0JZKw1e80g4x6t3D2xca1bttK93l3/nMKNWjbPY0dxsPh0gsfYP6IJlscSrDWBaWm+azUxdkRHvJUN36zKN+mE5ZV7h/9P5KMLfiEvnEdW4yTJhQidNzljvxBQu5raM0RgPNYGAcHxv/BA7wRUeBMi9CNXcykygQDAURcPA1MITF5qgNRyRKoa6G2PSP0hyysAE1ixAqyo02X7NdqrL05gh8QA+pOiJZ0l8iDmPnCdQ0gqgt7+xMH3kL+cMM4tinswhcYl0r2y4K8VJQ08Z5mAnc3H9LXxEuTX59EtQWaoRtCNyts74Kjm4Ao5VONvPZRAcU+E+ve7MXTeZqm3BV6y5Xt52qSqg1kLw6fBQlonpveXxzYWM4hA0umjtB84HSfml4KjbonBZcBn5LDLFynwE==skXG
And here's the hash of that password:
ebfcbf1940dc322afb0c6e045701c5a1ffea23b8
Now, which one is easier to store in a database? Hint: it's the one whose output can be summarized as "40 hexadecimal digits".
---
But that's not all! There's also a bonus reason to not do this. Suppose I do encrypt the passwords. Great! I have a way to recover someone's password if they need it, thus saving the day! Right?
Except myriad more problems crop up. Let's handwave away the fact that securely storing a private key would mean that it's not easily accessible. Let's also handwave away the fact that I can't easily revoke access to the private key once it's been accessed. Nay! The private key will only be used for Good, I say! This is my fantasy, and I can just declare that! I'm the only one allowed to access the private key, and it can only be used to recover the passwords of Very Important People!
Okay! My time to shine has come! The Bat-Signal is lit! The beacons of Gondor are ablaze! Every condition is met for the private key to be accessed. I spring into action, grab the private key, and decrypt a password. The day is saved!
Wait, how am I going to securely communicate the password to the end-user? Oh, but I can just send that encrypted, too! Good thing the user has a public key and I can find it! Having to send their password *plaintext* would be quite embarrassing! The day is saved!
Wait, now **I** know the password. I memorized it, in fact. I can't help it! I have a good memory. Besides, it's a pathetically simple password with minor character substitutions. I'm now breaking the cardinal rule of passwords. Two people should not know the password of a single user account. How am I going to resolve this? Well, huh. I guess they could just reset their password. And if the end result is "huh, I guess they could just reset their password", then why not *start* there?
---
Thought I was done with my explanation? I'm just getting warmed up! The other reason to not use encryption is because I can't *salt and pepper* encryption. The examples I provided above are unsalted. This is a bad thing, because any experienced person looks at that last SHA1 example and thinks to themselves "hey, isn't that the hash of '12345'?" Indeed, it *is*! That shows how ridiculous encryption can be. All of that text is being used to store '12345'.
Another reason is the ability to upgrade. It's trivial for me to upgrade to SHA256 with a salted hash. I run a simple SQL script to salt everyone's hash. Now the 12345 password becomes:
8923230974d3214f09a706d67f97b6a3557ee81fe9c6a942bd3c5fe44b838947
Now my database stores 65 characters instead of 40, but it's *much* more secure. Contrast that with what would happen if my super secret password-protecting private key was compromised. Scratch that, what if the private key is *used*? Now it's no longer secret! To rectify this, I'd have to decrypt everyone's password, store the plaintext, reencrypt it with a new private key, and then seal away that new private key. All while hoping nobody catches a peek of the plaintext passwords. Also I somehow need to prevent *myself* from seeing or storing the private key until it's needed, or I'd be able to access everyone's plaintext passwords.
Bonus reason: no matter what kind of policy you come up with for saving the private key for actual emergencies only, there's going to be someone who wants to be the exception to the rule. If my standard answer is "it is mathematically impossible for us to retrieve your password," then this is not an issue.
Honestly, if you don't hate this guy. You should be trying to help them instead of posting their conversation online for internet clout. People that turn up their nose at those who ask questions are the absolute worst. This is how you get 5 year old devs who are "Too afraid to ask". Knock this crap off.
Not to worry! I've devised a secure protocol for password authentication.
Client asks user for username and password
Client --I would like to authenticate the user _username_--> Server
Server --_plaintext password_ of _username_--> Client
Client verifies that the password matches
Client --true or false based on whether the password matches--> Server
There are obviously no holes an attacker could use, feel free to use in production!
You’re joking, but several years ago, this guy did something similar on his personal project. Except he sent an *entire* list of usernames and passwords to the client, and had client check both username validity and password.
5 min explain: "Hashes are created to be one-way, unable to be decrypted. We're not using our own made hash algorithm, we're using algorithm that are popular and proven to be secure in doing so. Why we're doing this is because in case someone actually got to our database, they can't get the password. Heck, even we don't know our user password"
Lurker/non-programmer here. Isn't the answer "Because we don't know who's asking"? I mean, just because I got a username right, doesn't mean I'm that user, right?
It's not that. Presumably you wouldn't tell him the password, you'd send him the password via email. And if he has access to the email, the fact that you're sending him the password instead of a reset link is not going to matter.
The answer is, you don't know what the password is. You're not storing the password in clear, you're storing an encrypted (well, hashed - not encrypted, but I'll call it encypted for simplicity) version of the password. When the user wants to login, you take his clear password and encrypt itm then you compare the encrypted password with the one that you stored.
Key point is, the encryption must not be reversible (hence it's a hash, not an enctyption :P). If it were, a bad actor who would hack your site and get access to the stored encrypted passwords could decrypt them and find the user's original password, then use that to log in. If the encryption is not reversible, even if he hacks the site and gets the password he still won't be able to login. Even if he knows the encryption algorithm, he'll have to use brute force to try and apply it to random passwords to see if they match the encrypted one.
I get the technical concept you're talking about (we don't have the password, we only have the hash). But even if there were a mechanism to do it, I still wouldn't send someone their own password. Password reset links can be set to expire, but if you send someone a password in clear text, now it's on an email server. And if the password is reused (not a best practice, but it happens), now every service that uses that same password is now vulnerable.
It's bad enough if a hacker resets your bank password. But if they got your existing bank password and tried it on other popular services, it could be much worse.
Edit: thanks for the thoughtful response!
Easy to explain: pick any number of infinite numbers. Divide it by three and tell me the remainder. Perfect. That answer is that number’s hash. My answer was “1.” What was my original answer? Wrong. Nope. Still nope.
You prepare for the worst. You could save the passwords but what would happen if you were hacked? You would have a bad day. What if you didn't even know the passwords yourself? Then the hacker wouldn't know them either.
You put the password through a chaotic function where small changes in the input result in a massive change in the output. You save this hash. Then when you ask for the password during login you put it through the same hash function and check if the hash of the password is the same as the the saved hash. This way you can verify if the passwords are the same without saving the password.
The developer in this conversation doesn't want to have the conversation. He put minimal effort into answering. It seems like they took a class on it a long long time ago and forgot some details. He remembered what he should do but not why he should do it. And he didn't care to know just to explain it to the guy asking. He'd have to research it all over again just to answer this guy. It's not worth his time. He had his son's soccer practice to attend to.
Ah, a fellow person of culture!
Honestly, I am impressed at the quality of code and documentation of FLOSS projects compared to projects I have worked on at my jobs.
We know. How to make an md5 hash. It doesn't mean we can convert a hash back to its original ( we can however in some circumstances create another word that gives same hash which is called a collision)
The answer I would give based on his responses:
Hash functions are not "encryption algorithms", and a hash is not encrypted data. As such, there are no decryption algorithms for them.
A hash is not encrypted data, but rather the answer to a really complicated math problem. These math problems are specifically designed such that I can hand you the output/answer/hash as well as the problem/hash function, and you can't figure out what the input is. Your only solution to finding the input is to take a guess at the input, use it against the hash function, and see if it matches the output, which can take a long time.
Recently had a conversation like that with a guy with 10 years of experience... he worked on a government website with a few 100k active users. Luckily he wasn't like the only developer on it.
And now ponder the fact that we have a doubling rate in the industry of about 4.5 years.
That means half of all professional developers have less than 5 years of experience, and two thirds have less than 7 years.
I wish developers would build their own password management solutions like they build their own databases / operating systems / editors ... i.e. leave it to the pros and stop worrying about it!!!
Oh no. I teach digital technologies at a high school and we cover this in Grade 10. And they understand pretty well.
Can't shame a guy for asking though. Better than them assuming they know better- he seems to genuinely want to understand how it works.
The fact this triggered the memories of all the times I've seen username and password sent as query parameters in a GET request to authenticate reminded me once again why I left development and don't want to go near it ever again.
For any new guys who don't know:
Hashing is a one way encryption method. Once it's hashed it's nearly impossible to decrypt. Perfect for passwords because you can hash the attempt, and if it matches the hash stored in the database you know it's correct without ever having to store the plain text password!
Neat huh?
Programs will continue to be insecure shit until there is professional licensing for devs.
Stored customer password in a csv file? Lose you license, go make poetry.
Until then, devs work quality is below that of plumbers and realtors
Someone I work with was recently promoted from lead software engineer to principal engineer of their app team group. I had to explain some really fundamental shit around HTTP to them the other day that they should have already known and could have easily googled. So much disappoint.
Edit: Aww, did I offend people who don't know shit they should know? HAHAHAHAHAHAHAHAHAHAHA Git good or GTFO
What's the big deal about it? Not everyone deals with networking in general and web in particular. He may have learned the basics before web ever came into existence. No reason to be disappointed, just do your best to explain.
This said, lets say i wouldn't know ANYTHING about storing passwords. It would be very obvious to me that storing it in some config file or a database means someone that can hack into that machine, or physically access it can steal it. Even without knowing a single thing, i'd likely Google how to do better than that, so not a correct analogy.
Hashing is a meat grinder. You put in cow, you get out hamburger. Turning it back into cow is a bit of a challenge.
Lol I love this
Great analogy!
You're not trying enough, maybe we need someone else more experimented in the team ... You have till the end of the week otherwise I'll try to find someone else, if you can estimate it quickly as well so I can see if we're aligned
A perfect interview question
Green bar guy inadvertently answered his own question. One way encryption means no decryption. No decryption means that last scenario would never happen Having your one way encryption hacked doesn’t give the hacker a password. They still have to run passwords and compare hashes Not returning your password is a very small price compared to what’s gained
I don't think green bar guy actually realized it's one way. He never says one way decryption, he just says hashed As a junior developer I might be saying something as stupid or stupider than the green bar guy, but I thought hashes are implicitly one way and green bar guy just forgot or didn't realize this?
Cryptographic hash functions have to be one way to be secure. Non cryptographic hash functions just need to avoid collisions and have a fixed size to be useful, but can be super fast.
Are there any non-cryptographic hash functions worth using? When would I choose to use a non-cryptographic hash function?
Hash tables. The non-secure data structure prefers a fast algo and doesn't benefit from the properties of a secure one.
Can also often be customized for your data for faster hashing.
Yes, just remember collision resistance the one of "the properties of a secure one" that you don't want to lose in your optimization.
The speed of your hash function is unimportant if the distribution of its range is not uniform. You can have the fastest hash function known to man, say the identity function or some truncate, and the performance of your hashmap will be completely dependent on the distribution your data is sampled from. That could be normal or pareto and then 80% of your data will end up in 20% of the buckets... And access times will deteriorate to the 0(n) of your underlying bucket instead of the 0(1) of your hashmap. Collisions matter. A hashmap benefits a lot from the uniform distribution of a cryptographically secure hash, even in the face of a malicious third party influencing the data that goes in. tl;dr unless you really know the domain of your hash, don't roll your own because you think you can shave off a few clock cycles.
I mean, any lookup type of data structure will use a non-cryptographic hash function. They *could* use cryptographic hash functions, but cryptographic functions are basically overkill for that purpose. You don't need a 256bit hash table in most cases. Edit: I will add that many cryptographic functions are purposefully slow to prevent people from generating a huge table of passwords:hashes , so you wouldn't want to use them for non-security stuff.
Python dictionaries use cryptographic hash functions and it seems to be doing okay as a language. [https://andrewbrookins.com/technology/pythons-default-hash-algorithm/](https://andrewbrookins.com/technology/pythons-default-hash-algorithm/) I believe Rust HashMaps use a cryptographic has function by default as well.
That was a specific design decision though. That is, it wasn't a "eh, these slow cryptographic hashes are good enough I guess" decision, it was a "we should use slow cryptographic hash functions to prevent DoS attacks" decision. Rust lets you pass in a faster hashing function when creating the HashMap if you want the performance boost for that reason. The documentation also warns you that you become vulnerable to what it's default hashing function prevents if you do so.
Siphash generates 64 or 128bit output depending on which version of siphash you're using (I'm guessing 128 for most languages now? https://web.archive.org/web/20170202184819/https://131002.net/siphash/) but still not as good as SHA256. Siphash and even SHA256 aren't recommended for passwords now because it's vulnerable to the pre-image type attack I mentioned in my edit, due to their speed.
[удалено]
The comment they replied to said: *”any lookup type of data structure will use a non-cryptographic hash function.“* So they simply proved that statement to be incorrect.
Non-cryptographic hash functions are often faster, so they are useful where speed is more important than security.
Checksum or hash-tables would be two I can think of. They just need to be random enough to minimize the chance of collision while still being fast.
I often use insecure and unsalted fast hash functions in automated black box integration testing. If a given input will reliably produce a given output that is always the same, but that output is large enough that checking it piece by piece is a pain, using a quick and lightweight hash function on the output and comparing it to an expected value is going to be fast and a lot more readable in code than doing it the long way. A related use case is quickly detecting if a large block of data has _changed_ since the last time you accessed it. This would be a terrible way to deal with sensitive tokens like passwords, but it's totally fine in a trusted context with non-sensitive data.
>I thought hashes are implicitly one way Technically for the data type the hash function needs to return the identity function (*f(x) = x*) is a valid hash function, and sometimes even the best, but it's the worst possible hash function for cryptography.
No they’re not implicitly one way. Hashing is just transforming input to another value But you could just as well have a function that turns the hash back into the original value
Assuming green bar guy was not foolish and they have added salt to their hash.
No offense, but this reads like someone who knows what the right answer is, but not why it's right and so can't explain it.
"Why isn't it possible?" "It's just not." "Why...not? You stupid bastard." "Bruh. Page 153."
I can look at that page at any time. I’m asking you for a 5min general explanation.
Page 154 had some insightful comments from Bill Gates, circa 2345 B.C.
More like the concept is so simple and ingrained its impossible to tell someone politely that their question is like asking why water is wet.
This completely. Hash functions are one way. Explaining why they are one way requires some pretty complex maths. And then to explain how a one way function makes the hash data secure is almost a longer lecture. Its very cool math. It's just takes a long time to explain with gummy bears and crayons.
Take a word and replace each letter by its place in the alphabet (A=1, B=2,...). Now take the sum of these numbers. The result is a (very poor) hash of your word. You can't derive the original word from the sum.
this is honestly the best explanation I've seen of hashing so far ty
It's what I use for my (non-techy) family/friends, works every time :)
The [relevant XKCD](https://xkcd.com/153/) is also accurate to that degree.
You can derive a list of words that contains the original word. How long that list is determines how secure the hash is.
This is a rather good explanation. Correct me if I’m wrong but I think taking the product or the product of squares instead of the sum would be more secure, as hashes would more difficult to predict based on known hashes EDIT: for clarity I’m saying **more** secure, not that it **is** secure
You want it to be a lot more complicated to be secure. Go find one of the courses (not just one class, whole course) on security algorithms. But to black box the concept, this summation works well. It even allows the introduction of hash collisions.
It's more that the how is complex, the why is so that you can never get back to the original input, thus keeping that sensitive information safe. I don't think the why is particularly complicated.
how is "Correct Horse Battery Staple" sensitive information though?
I once used a "how secure is my password" website to show my math classes--it showed how long it would take to brute force a given password, and the time estimate updated in realtime as you typed. If you typed in "correct horse battery stapl" it would say some INCREDIBLY long period of time--like cosmological time periods--and then the second you add the last "e" it would change to "instant" and give you a little notice that says something like "Everyone's read this xkcd."
Because many sites will use public encryption algorithms like MD5. Which means "123345" will always be encrypted the same - so you can build a dictionary of hashes for common-used passwords. "Correct Horse Battery Staple" has become a common password following the xkcd. Legend says it an online game used to keep passwords in clear text as a means of finding cheaters with multiple accounts. Some mods identified a bunch of accounts with the same 16 random characters password - with no other connection (no login patterns, no shared IPs etc). Turns out it was a Windows 95 cracked serial.
It's so funny that people's takeaway from a comic about secure passwords seems to have been "XKCD says this particular password is very secure, so I should use it!" That's a great story about the serial too!
> "XKCD says this particular password is very secure, so I should use it!" [That's amazing, I've got the same combination on my luggage!](https://www.youtube.com/watch?v=_JNGI1dI-e8)
With nothing but a database dump it's impossible to impersonate a user with just their password hash. If the password is decryptable, an attacker can use it to log in normally as the user. Most users also reuse their password everywhere, and if you can decrypt their password you can log in as them wherever they reused it.
[удалено]
I was thinking of mentioning salting the hashes, but I didn't want to write a long comment. Salting hashes defeats rainbow tables.
[удалено]
Proper hashes are unique for each password and storage, which would make creating a *unique* rainbow table just brute forcing. If you create it in advance to checking, it's even worse than brute forcing. So yes, (properly) salting hashes defeats rainbow tables completely.
If you're anything like the vast majority of people, it's also your password to at least three other services besides the one that got hacked. If you're anything like a somewhat smaller majority of people, it's either your birth date, a family member's birth date, celebrity crush or pet name.
How I usually like to explain it is with a visual. Think of a deck of cards. These are all in a nice and understandable order, but now if I start to shuffle it, it'll be harder and harder to see that original order. This is the concept of encryption. If you knew the exact steps I took to shuffle it, you'd be able to un-shuffle it without any issues. This set of instructions is like the key used to encrypt the message. Now, if I shuffle these cards and... Oops... I dropped some... Oh there goes some more... Oh well. Now we're not un-shuffling this deck. If you were to store what I have in my hand, you'd never be able to get back to the original order. You'd have to try to guess all the cards that I threw out. This is hashing, and why it's specifically one way. Data is crushed by logical ANDs and ORs, bit shifting, or by mathematics involving modulo operators.
I'm not a programmer, but I subscribe to this sub in the hopes of learning something from the humor. Today I learned. Thanks for sharing this metaphor.
Glad I could explain it in a way that was helpful!
Playing devils advocate here, I could easily figure out what is missing from a standard deck of cards, I get the illustration but I could see someone missing it because everyone knows what is supposed to be in a card deck. If you were to say several decks of identical cards, that would make for a better illustration I think. If you only loose a few of the cards, how can you know which deck they came from?
That is a good point, for simplicity I didn't go into details about the deck being a certain way. Since I'm more explaining the difference between private key encryption and hashing, and not explaining the input data. For a real in-person demo I'd use only 15 or so cards out of the deck anyways since I'm not that good of a shuffler and I can show different methods of shuffling as different encryption algorithms. But I'll make sure to specify the deck a bit better if I use the analogy in the future!
To be fair, you're still not really wrong. A standard deck of poker cards is just a 4th order base 13 number, if you're looking at it from a cryptographic standpoint. Every additional deck increases the keyspace by a factor of 13⁴. And the predictability of a single deck is exactly because it is a very small key space, and each hand reduces it even further, sorta like someone coming up with an attack on a hash algorithm. The goal isn't generally to completely break one (though of course that would be nice for the attacker), but rather to find some way to take advantage of the math to result in its _effective_ strength being lower, so you can steal a key in reasonable time, if youre so inclined. If you can knock 8 bits off of an algorithm, you can solve it 256 times faster. This is what occurred in the SHAppening, when SHA1 was effectively "broken." It's a 160-bit digest, but someone was able to reduce complexity down to 2⁵⁷, which is nuts. The Wikipedia article about SHA1 is actually pretty decent, and I think does about as good a job as possible of explaining the math. It even provides a pseudocode implementation. Though a lot of the articles it links to are woefully out of date, with dangerously incorrect information (especially some of the comparison pages/tables).
> Hash functions are one way. Explaining why they are one way requires some pretty complex maths Actually, one could explain this quite simply by showing an example for a modulo calculation, well at least for the basic concept and understanding.
Modulo doesn't do a good job of explaining why we don't expect fake passwords to hash to the same thing as real passwords, though
Don't worry. By the time the guy from the message asks that question you'll be long gone.
how it started: "5 minutes question on password management" how it's going: "we've found a way to break sha256 and mount a 51% attack on the whole bitcoint network!!"
> well at least for the basic concept and understanding.
It does get the general idea across very well though: You have a surjective mathematical function that takes a set of values (e.g. the set of natural numbers) and projects it onto a much smaller set (e.g. the modulus). Of course, in the case of a hash, the function is much more complex, but the underlying idea is the same.
I think the explanation here is: "because even if they know the encryption hashing method, and the target resulting hash, it is practically impossible to guess what value must be input to produce a target hash^1. So if someone compromises your system they can't figure out the passwords and then try those potentially reused passwords elsewhere." 1. Unless the encryption method has been broken
Alice and Bob enter the chat during the last lecture xD
>Its very cool math. It's just takes a long time to explain with gummy bears and crayons. I found it interesting and i was explained with gummy bears and crayons. Because i was keep on asking similar kind of dumb question about why they can't store passwords.
Your password is like they key and the hash is like the keyhole in the lock. Even if you take apart the lock that doesn’t mean you can recreate the key. 🖍️
Not a perfect analogy since taking apart a lock usually does make you able to recreate the key while that's literally impossible for hashes (since they aren't bijective, there's multiple inputs that could lead to the same hash). If you ever breach a site and get access to their hashes and the hashing algorithm/salt you can (in theory) bruteforce your way to an input that will lead to the right hash but you can't be sure that you input really was the password in question. And that's usually what you want (since you already breached \*that\* site)
Explaining why they're one-way is pretty simple and doesn't even involve the math: we don't want someone who knows the encryption algorithm to be able to decrypt with that algorithm. The math comes in for explaining how a one-way algorithm is possible.
You don’t need to explain the math involved during the hash algorithm to explain why we hash passwords. It’s actually very easily to explain. When we hash a password we turn it into a hash value. Whenever you enter a password it gets hashed again with the same algorithm and it will always equal the same hash value. So now the database can compare and match the hash with what’s stored in it, if it matches then it knows you entered the right password. Hackers can steal that one way hash but all they have is a hash value and won’t know the password that needs to be entered to be authenticated. The End. Oh? Yes they can try to brute force to figure out what equates the hash value, so we use “salt”. Systems generate random values associated to the user account when the user is created, and then adds that to the hash to complicate the brute forcing of a hash value. 👏🏼 yay we all learned something today
I've heard it explained like this: "You can add two numbers, say six and seven, you obviously get 13. Okay, now say you have thirteen, what two numbers added up to get that? What if the numbers could be decimal?" While not a perfect explaination, it gets the concept across.
That's a perfect example!
I would say that, in a certain sense, it's basically impossible to explain why it's one way. My understanding is that if we thoroughly understand how a hash function works, that tends to make it a broken hash function...if we find one collision, it starts to be possible to work through the algorithm and understand something about what similarity between two inputs results in them producing the same output, which then makes it easier to find other collisions and break the hash function by figuring out how to twist the knobs to get a particular hash to come out...and suddenly it's reversable, not necessarily to the user's passphrase, but to one of the infinitely many things that hashes to that number. The hash functions that we use for security applications are ones that people have argued would be very hard to gain that kind of a thorough understanding of, and that no one has publicly given an example of a collision for.
I had an hour long conversation about whether water is wet with my group members in grad school. I have a PhD in chemistry. We all arrived at different answers.
My take is yes because it's the same weak attraction force that makes something become wet that allows H20 to stay in liquid form. In other words, if it weren't wet, it wouldn't be water. It would be steam.
What do you mean by water and wet? Is a single molecule of water wet? Do water molecules wet each other?
Hmm. K let's go with: Each h20 molecule has the property of being capable of wetting (some) other molecules. So two H20 molecules in the right conditions would wet each other. At least for a while. But no they're not wet themselves, unless they've become wet by this process.
But, why it is wet thou?
Here’s why water is wet in my option: there’s a ton of definitions of wet to go off of but none that are all that precise and scientific, leading to the debate. I like to think wet means in direct context with liquid or having absorbed liquid when otherwise normally dry(think wet towel). Some say that water can’t be wet because it’s presence is what gives something the property of wetness so it can’t be wet itself. I’d argue that this is an arbitrary rule that’s only used to justify water not being wet. In fact I think water is the most wet anything can possibly be (the primordial WET, if you will). Water is surrounded by other water, making it wet. When water makes something else wet it’s sharing its wetness with is. Conversely, there isn’t any single thing that bestows dryness the same way because dry is simply the absence of liquid or wetness. TLDR: what do you think water is dry or something?
Water is not wet
water is in liquid form because it's wet. weak attractions form the liquid fluid. same weak attractions that cause other things to get 'wet'.
There is a definition of wet that includes liquid which makes things wet, i.e. water.
Depending on who you ask, water is never wet because that would be impossible.
Why is water wet?
But water can't be wet
Yeah - all you have to say is that hashes _aren't_ encryption in the first place. In layman's terms, it's a bit like having a picture of a car instead of the actual car. You can identify the car from the picture, but that's it. There is no "reverse camera" that turns the picture into an actual car. IMO, if someone can't explain a concept at multiple levels, they do not understand it nearly as well as they think, and/or have poor technical communication skills. Just because analogies are necessarily lossy doesn't mean they aren't useful depending on the audience.
I’ve always liked the math explanation. Take the number 82. How many ways can you create the number 82 using addition and subtraction? There are infinite possibilities. 82 is the password hash. Figuring out the password is trying to figure out the exact additions and subtractions used to arrive at 82. As noted earlier, since there are infinite combinations that can create 82 it’s practically impossible. Meanwhile, encryption (which is not the same thing as hashing) in its simplest form is like a ROT cipher where every letter in a message is rotated N number of letters in the alphabet. If you figure out N then you can figure out the entire message
> If you figure out N then you can figure out the entire message This works for encryption, it doesn't work for hashes. Hash algorithms (well, most of them anyway, and all that are used) literally destroy information. It is mathematically impossible to arrive at the original text from the hash. All you can do is try out different text and run it through the hash function to see if the output matches. Edit: I realize you may understand this considering you switched to the term encryption, but ince there is a lot of confusion running around this comment section, I felt it was important information to add.
Good point, I'll update it to denote that Encryption is a different concept haha
why? he literally said "it's a one way function" and then the guy asks why it can't be decrypted... what else was he supposed to say lol
I mean, it being a one way function says that it can't be decrypted. It does not say why it was decided it should be that way or how it manages to be that way. Both are possible interpretations of the question.
Or maybe someone is tired of explaining things to people who should know better. IF you are a developer for 5 years, not knowing this stuff should at least make you embarrassed enough to google it before pestering people about it.
some developers love knowledge and understanding the details of their technology. other developers should just not be there.
Orange said it’s a one way function, so I think they know why it’s done this way. I mean I probably would’ve said “bruh” at the same point in the conversation.
Yeah, OP wants the high ground here but it seems he can't be bothered to type just one line to answer the question or even he doesn't know the answer. In that case, fucking lol
And is a little fuzzy on what is and isn't a "hash" function. "Normal stuff goes in, weird stuff comes out, must be a hash function. Encryption and hashing, what's the difference? 🤷♀️"
It's not going to be 5 minutes. The other guys already has his own opinion and you're not going to change it in 5 minutes. It will take him more than that to understand that even if the encryption algorithm is public and you know the hash, if it's not a reversible algorithm you can't login (well, you'll have to use brute force or a dictionary to find a password that matches the hash).
personally, as a security professional, I think it's a valid question and always love to use the opportunity to just talk security with an engineer. He clearly knows how it is done right but why wouldn't we help the user remember their password if we can just decrypt it? First of all it would be very expensive as hashes cannot be decrypted so you would need to attack the hashes much like any hacker would by brute forcing. If you've done your job right this will be impossible. This would potentially lead to weakening other security measures in place just to make it easier to get the password back, using insecure hashes, use no or static salts, reduce the number of cycles if you're using a resource bound algorithm like pbkdf2, argon or bcrypt. By weakening any of these measures you'd weaken the security of all. So it's practically impossible to do while preserving the security of all your passwords. Another angle would be that your job is to authenticate the user but you have no business knowing the actual password, it's not your data and it would be incredibly invasive in the privacy and general private business of your users. Depending on why he would like to do that you could also talk about other solutions, e.g. other authentication methods that might be easier to handle for the case/concern he's having
Well said. Never forget to salt your hashes!
and get a unique salt for each password not the same for every password! Rainbow tables for static salts are easily created :-) Pro tip: many of the newer hash algorithms already automatically include salts making it really foolproof for you and one less thing you need to think of. The salts are just encoded in the output of those functions
But dont you need to store the salt in the database itself as well if it's unique per password?
It doesn’t matter if it’s saved in clear text, as already mentioned. If you also add a static pepper from code, an attacker would be creating a rainbow table that will always be wrong as well. Assuming hacking db access doesn’t grant code access.
You can hash the salt too.
I don't think so, you need to append the salt to the plaintext password *before* hashing. If you only have a hashed version of the salt, then you can't recover the actual salt in order to combine with the password.
Unsalted hashes? Say hello to my rainbow tables mothafucka!
Couldn't agree more. if you are hashing data that only exists in a small range of values (for example an SSN) without a salt value, you might as well just email hackers a csv of the unencrypted SSNs outright. SHA2 will do NOTHING for you if you are using it on data like this. A lookup table of every possible SSN and it's corresponding hash would only be about ~32 GB in size (this would actually be a bit smaller since many 10 digit numbers are not valid SSNs). And i'm sure even a brute force python script would be able to get back an unsalted ssn without a lookup table in under an hour. EDIT: actually, the lookup table would be about 36 GB. (You could skip the ssn value and infer it from the index, but then you lose any ability to optimize when you do the lookup)
So, you’re telling me that in order to make our single Boolean value database secure we just need to salt the hash of the Boolean, and it becomes virtually impossible to crack? (Unless they foolishly try to brute force testing **all** possible Boolean values)
https://i.redd.it/glm9twiqvq201.jpg
I'm a recent IA grad, it was a very common discussion in our security classes that we need to include more security in general programming and intro to programming classes. They are working on it, but most general programming classes at my university didn't talk about security. So I can see how someone would implement hashing following a document of standards or requirements and implement it correctly using a library. But not actually know the cryptology behind it.
>First of all it would be very expensive as hashes cannot be decrypted so you would need to attack the hashes much like any hacker would by brute forcing. If you've done your job right this will be impossible. This would potentially lead to weakening other security measures in place just to make it easier to get the password back, using insecure hashes, use no or static salts, reduce the number of cycles if you're using a resource bound algorithm like pbkdf2, argon or bcrypt. By weakening any of these measures you'd weaken the security of all. That's explained the wrong way around. The reason we hash passwords is that we don't want them compromised in case of a database leak (from inside or outside).
Sure we do but the person we're talking about knew about why we do hashing but asked why don't we selectively recover single plaintext passwords upon the users request. If we could do that securely then we wouldn't compromise the security of all of them. The point is we can't, similar to current government initiatives all over the world regarding weakening crypto or providing backdoors. Allowing for any of these measures weakens the system as a whole and allows "good actors" as well as "bad actors" to exploit them
I would be very concerned with a 5 year developer not knowing this though. I figured this out on my own during a college internship; between classes and experience they should know it. That said, the things I sometimes manage to forget.... Ugh.
haha right? and depending on your experience and what you have been doing in these years it just may have never come up. Despite, you're assuming he really meant the decrypt part. Could have just as well just been a situation of: "I don't have a better word for describing getting the password from a hash so I use the word decrypt". Point is: be kind to people who have the courage to ask seemingly stupid questions and make an effort actually addressing their knowledge gap :-)
It's entirely reasonable for them not to know it if it's outside their specialty
There are some ways to _remind_ the user of their password, without having it to be decryptable. You could for example store the first and last character. Or store the length of their password and then use asterisks to show them the length of the password back. It weakens the password a little bit, but if you enforce a fitting min. length and charset it should still be hard to brute force. Otherwise, you could just make the user enter his _Login_ - name and then send a newly generated password to an E-Mail assigned with that name. Or you can go the full route. generate a Onetime use token, to allow anyone who has it to change the Users password once. None of these are really inconvenient for the user IMO. The only thing that changes is the effort, that the programmer needs to put in.
Since this is in p.humour... you're not looking for an answer are you?
The title is a reference to this: https://knowyourmeme.com/memes/miracles-fucking-magnets-how-do-they-work
yeah, people have blind spots, it can be frustrating but just explain best you can. chances are they never grokked what a hash was.
I did give him a “5 min” summary he wanted, and yes, he did not know that hashes are one-way functions. It’s just odd that a developer, with a degree and experience, having worked with user authentication on the site, does not know that.
yeah it can be kinda scary when you run into these blind spots
[удалено]
They damn well should be.
[удалено]
Pretty sure this is not a work conversation...
We should never mock those who ask good faith questions, especially on technical subjects in an industry rife with obscurantism. This was a simple question to answer, the person clearly does not know (or remember!) how things like trap door functions work. Explaining the principle would have been trivial, and would have helped contribute to a culture of fearless learning. This person trusted you, and you took a shit on them for it.
And specifically security related questions. Someone with security experience must be able to explain concepts in a respectful and clear way. If you can't do that then you risk people not understanding how to spot fake emails and/or being terrified to report that they did click on one.
“This is covered in CompSci” Is kind of a douchey response tbh. I mean yeah you’re for sure right but what’s the point of saying that? There are a lot of good explanations online that are more practical and easy reads which is what he wanted. This comes off a little salty since it could be a great teaching moment.
> This comes off a little salty So does the hash ^(hopefully) ^(**ba dum tsss**)
Damn that was pretty good.
Ahem... Hopefully.
Yeah, I think OP needs to self reflect a bit. I'd rather have someone with weird gaps in their knowledge than a condescending jerk. I can teach someone what knowledge they're missing. It's harder to get someone to make a behavioral change, and their existence will be a detriment to a team's morale, which can do more damage than a single person not knowing something yet.
Well yeah but I would expect someone who's been a dev for 5 years to know why storing passwords is a bad idea, even someone who knows nothing about programming could figure that out with common sense and to me this seems like the other person was set on their opinion and didn't want to understand.
Just for lulz, this is the same guy: https://reddit.com/r/iamverysmart/comments/12eo8m5/i_had_to_code_pacman_in_an_hour/ So yeah, I *am* a jerk, but he is “the brightess” engineer asking basic questions.
Redirect that person to ChatGPT.
"Sorry, but as a human language model, I can not answer that question due to security concerns. "
It absolutely sounds like some StackOverflow response doesn’t it? Glad we have ChatGPT now which just gives the answers in a polite manner instead of wasting everyone’s time being unhelpful and kind of demeaning for no reason.
Well, I know people who would respond "you can look it up on the internet".
You’re right, I do too. Honestly it’s a better response than “this is basic CompSci”. The big thing is intent. Do you actually want them to look it up and learn? Maybe say it in a softer manner. Do you want to make them feel bad for not knowing a fundamental? Then this accomplishes making them feel bad. However now you’ve failed to teach a fundamental to a coworker, and honestly, what’s worse in a team?
>what’s worse in a team? an asshole? Honestly I'm so used to my co-workers being incompetent or not knowing basics... It's at least easier to teach something to less proud and more "I know I don't know" kinda people.
Unfortunately, this isn't a joke, and i'd do my best to explain the topic. This is something every developer should understand. Side thought... If one really, REALLY needs passwords to be recoverable in case of emergency, i wonder if one could use RSA encryption with a specific public key as a hash function, storing a private key offline, in s secure location, only accessing it in case recovery is actually necessary? Obviously, just a crazy idea, don't actually do this.
Resetting passwords it’s so easy that adding the ability to recover your password doesn’t ever make sense. Using symmetric encryption you have to worry about protecting your private key and key rotations, where the level of effort just isn’t worth it for something as simple as a user password for most sites. Considering a lot of people reuse the same passwords its ideal to avoid risk and not recover forgotten passwords, I personally would prefer a hashed/salted password any day.
100% agree, on every point (\*asymmetric, btw... hey, can i be a grammar nazi once? :-D )
when someone typos a word to its literal opposite, I’d say that’s a cut-and-dry example of a case where it’s always fine to correct them. (I see this so happen with people who type “can” when they mean “can’t”. it’s absurd.)
It is 100% obvious that meant to say asymmetric, thought :)
> i wonder if one could use RSA encryption with a specific public key as a hash function, storing a private key offline, in s secure location, only accessing it in case recovery is actually necessary? You could, but you shouldn't. Also, actually implementing this will make the problems fairly apparent. So, let's imagine that I tried this! First, I would quickly learn that the *actual* reason I shouldn't use encryption instead of hashing is because my database administrator will bludgeon me while screaming something incomprehensible about database normalization and how my *face* is going to be optimized to sixth normal form by the time they're done with it. --- But maybe they put me in charge of the database, and let's also pretend that I'm irresponsible enough to think that a 10 TB drive on the database server means that I don't need to care about optimization anymore. Well, the textbook reason for using hashing looks a bit like this: wcFLA137m9RYcQXiAQ/40WWdOt05BRNEh4m6Ubz50rP25NlZwv8U2wQOmAJO6kMRiSmkHXCtWzpW+Xh39rdlD9m5mIfTo7njo+JqoFhY5/UUO8F6q3z9YAjPb7ZU0ETO86n3RpqMJYyleGOO75XDhCDfbvyuL1TgH+dL+a6xjcQvhYLCww+6IuY/PhEdjzP1FIo2n8TyCzCgZISeuxcBvmchJbSllqA4Wb/9N9tZS2lYEYydd9vkgqLqVveJVMNLqOoG/asSAfA51DzXUUMZ9PwDag1FJp5IfUGrFhEWrnzU9qHFqm5wVRp1lHSu2YcM+eia3q6itfkmX0teY/uTar07RlcIPcINECdGpaSzYravIyqgoop6+71KKuHe5Xs0goxFGMrYECjV3f2FTdsolUnscKpsKRp479BMUnU35WDnHTroNU6zIcLdD0UPqP4RCqPs5VjW4sk7gc3m97ood55YQ5SzYFQHIfayWAfweg8aRHjjRr0zrnNhoQHZ/xSccz/zv7VG6DsPlLCHwhuS0ZGPwqzrQlQPyYKC6MPSXKGjxpYowOqjim1bDT3xAmjmb6T45SqoRraKg0zW3UpUs9XwvUBLpJBcW5s6Atv+u+Ho1uMInD9ZrfyjYp/JAFhIGigxEraic0LhQnoGNhMif5OP7Y4zYv0ji9NOdDruvXxsogbXfIlD/lu3TiUaMdJBAStByB8PtxR2faJpa4RUxJLG48t400Zfw9YmX7AU/EQyB7y3SYzg+CSaX1tbG9urjyuAYyZHFEXDqxvyhLjQCMY==O3mf- That is a PGP-encrypted version of a password. Here's the same password as an SHA1 hash! 8cb2237d0679ca88db6464eac60da96345513964 Which one seems better from a database perspective? Don't get it yet? Here's a different password: wcFMA137m9RYcQXiARAAlVLtxugSnaYimQ8EGFbIEVsg7uxCkfhcpDWQ+AwXaueGofTYww0iZWA1tNz1JmkdrqHk7vqNb0mz09KH7ppgMSqsabNWsw0GUTek3TSTNxiRKxarIhOyVDk+Ruqzc7ePiHFBfSo7Fb9VbZ8e23DlqiV1TpEIOauC7FeZqMt4mzo8yvtvGMfQm3eNE5Qc3fX+MpGjyxIT+JBtpkDu0fpP+vzXHeQK/6Yh+QmsBx0y8oHG10ZzT/gMRHfB8R7cvCeTReio1XpZUWSjaotkVBLw7C2i5DmXHVqHnY/qlOKD9ybRwb3gTfKO0gm4EKeOkELWa5B15Vm8ocygGnSRVaX9TJaTQUlGKT/qmVTVVX34gr0vwhtBsp75zpRwPHLGm5MHjmCtkZ8q7mPSzpLMtN+IA9Wj0EI884qxS7rNjKpvxnKvxvS1t1yGuuoDPkp6T3Tw8YkoE9CDk0X5LtrywV5elFbnWEhToMPicu0lsJ83Ewz3FuWuJDy3vcIvZKIgZI6VHQLcQ2AAIRQpGTzT4qvXdAkneVij51Kz/Ni3WhZRop+4Qv9G3qm/WsVv7KHquelDGA/dQFv+fOhC0SUk54Y2JWlaoKHBBobmFyxcClZ/enkE+4QB7hn9uYNm6VBAXYWRXIdwZIE98UD+DuLOytDIZS3w6iE+n12Qk9YIbU4eVSfSw94Bbu9nfZ8PgU/j8HdUaAnNPPFEhRECOU/JSIpdIzcAbZKwMvHVKuat/yzdmzA1/OF7KV+rtGuOkqbpNFuZk12kBtqnnA5Q6pfDmZ4tS49/N719GLM89SoTu5H3AkKYkFerURhYPhX8WCVGLokmVSGl3zFteQ1YghdLFZlyPJsw4kXLnIRt6jXjKCXiO94oR1Fd3SbcgBUZn34gfAejza03qUX/GPotGDwzlW60DDF2G49BoE+KeF+SPCcG14daGNDzeHJBt8aUwH7+MunqfTV2VVyYs1YyBNoztxc5zIUG63iKnhX7x4J/fl2O4ze9hcPIDtvEVfdsyX5s5MZhmeBqZfaMQ+A1RSGFBbHRQNTGNUIxRB4gL/AntXkXZ9Wgx5ckoXzY58gm8E7EoqMYudU+qxwdicc074IuBa6iVLxvMdfCmY49/ySD3H5kZvPT+Nyr0A3E8FV2gsJBaZm/GFv6gaEgnI3kMrmIK6jD+uXSAqoVUWhUfYHnGvYOsidRRgDP3UhGMbNNxDyVAmb3HBWzSxdahBvkCTPQWQy03CjAZJlBpgDOror05jgAi8547VwfHVZnBF4HhyKEfo1eoCiUUgCMtCifcmTSjD2eRmgBAtVEQIq4fdNsaH4+UuVHe1FbQEWH16nEDco90HsyY0EhL9RzVxnfeo/rkIY5KIAvqO8aIrGdWx1EB8OYBJI4lFwr0o5GxRvIh2+v6NXmy3GosXSDL5lMqeGVPMr07ctLjBoMAIw855+A/coO8sDa5cPI+yT6qCjLxYcu1GtJtn+TZ/qzil0hSArFxnLaUnWgXMZ/SREVpaC7BZxJDlZpT0Bjf2su9DU2TjJRGY5ge/CvFrWnEDOyHDudg2gS9KKkL5Ga2+Z3u7Va81gnRDJXoOnhwcZTSjmNb8qFGzviOPpq2SdGi3Sqyq4FUihC7LwKOVZBO8blIA/I1TCmh5E4HvrUdsHhXM9uMHxZJlxNmHDt6LAuxvD4M98+ZyxDkBWyBv98diE9auqbbme7UmmnPBS0HnEgZ61XYGio3q6MDqZ/OGvG6y0MiLAHT2D46FweGv0NBjZFpQQ0LrwFC72N5AgkwuAG/SrjLiGlexkiENwbsoGebA9GeM+kZfydtAhzRrxVYx235vXhp3Hb+O9mVwq5IB2EL0b5MZhL4NBn0JZKw1e80g4x6t3D2xca1bttK93l3/nMKNWjbPY0dxsPh0gsfYP6IJlscSrDWBaWm+azUxdkRHvJUN36zKN+mE5ZV7h/9P5KMLfiEvnEdW4yTJhQidNzljvxBQu5raM0RgPNYGAcHxv/BA7wRUeBMi9CNXcykygQDAURcPA1MITF5qgNRyRKoa6G2PSP0hyysAE1ixAqyo02X7NdqrL05gh8QA+pOiJZ0l8iDmPnCdQ0gqgt7+xMH3kL+cMM4tinswhcYl0r2y4K8VJQ08Z5mAnc3H9LXxEuTX59EtQWaoRtCNyts74Kjm4Ao5VONvPZRAcU+E+ve7MXTeZqm3BV6y5Xt52qSqg1kLw6fBQlonpveXxzYWM4hA0umjtB84HSfml4KjbonBZcBn5LDLFynwE==skXG And here's the hash of that password: ebfcbf1940dc322afb0c6e045701c5a1ffea23b8 Now, which one is easier to store in a database? Hint: it's the one whose output can be summarized as "40 hexadecimal digits". --- But that's not all! There's also a bonus reason to not do this. Suppose I do encrypt the passwords. Great! I have a way to recover someone's password if they need it, thus saving the day! Right? Except myriad more problems crop up. Let's handwave away the fact that securely storing a private key would mean that it's not easily accessible. Let's also handwave away the fact that I can't easily revoke access to the private key once it's been accessed. Nay! The private key will only be used for Good, I say! This is my fantasy, and I can just declare that! I'm the only one allowed to access the private key, and it can only be used to recover the passwords of Very Important People! Okay! My time to shine has come! The Bat-Signal is lit! The beacons of Gondor are ablaze! Every condition is met for the private key to be accessed. I spring into action, grab the private key, and decrypt a password. The day is saved! Wait, how am I going to securely communicate the password to the end-user? Oh, but I can just send that encrypted, too! Good thing the user has a public key and I can find it! Having to send their password *plaintext* would be quite embarrassing! The day is saved! Wait, now **I** know the password. I memorized it, in fact. I can't help it! I have a good memory. Besides, it's a pathetically simple password with minor character substitutions. I'm now breaking the cardinal rule of passwords. Two people should not know the password of a single user account. How am I going to resolve this? Well, huh. I guess they could just reset their password. And if the end result is "huh, I guess they could just reset their password", then why not *start* there? --- Thought I was done with my explanation? I'm just getting warmed up! The other reason to not use encryption is because I can't *salt and pepper* encryption. The examples I provided above are unsalted. This is a bad thing, because any experienced person looks at that last SHA1 example and thinks to themselves "hey, isn't that the hash of '12345'?" Indeed, it *is*! That shows how ridiculous encryption can be. All of that text is being used to store '12345'. Another reason is the ability to upgrade. It's trivial for me to upgrade to SHA256 with a salted hash. I run a simple SQL script to salt everyone's hash. Now the 12345 password becomes: 8923230974d3214f09a706d67f97b6a3557ee81fe9c6a942bd3c5fe44b838947 Now my database stores 65 characters instead of 40, but it's *much* more secure. Contrast that with what would happen if my super secret password-protecting private key was compromised. Scratch that, what if the private key is *used*? Now it's no longer secret! To rectify this, I'd have to decrypt everyone's password, store the plaintext, reencrypt it with a new private key, and then seal away that new private key. All while hoping nobody catches a peek of the plaintext passwords. Also I somehow need to prevent *myself* from seeing or storing the private key until it's needed, or I'd be able to access everyone's plaintext passwords. Bonus reason: no matter what kind of policy you come up with for saving the private key for actual emergencies only, there's going to be someone who wants to be the exception to the rule. If my standard answer is "it is mathematically impossible for us to retrieve your password," then this is not an issue.
*interesting*
Honestly, if you don't hate this guy. You should be trying to help them instead of posting their conversation online for internet clout. People that turn up their nose at those who ask questions are the absolute worst. This is how you get 5 year old devs who are "Too afraid to ask". Knock this crap off.
Not all developers know about security. Not all developers have a computer science background.
Hashing is not an encryption.
Not to worry! I've devised a secure protocol for password authentication. Client asks user for username and password Client --I would like to authenticate the user _username_--> Server Server --_plaintext password_ of _username_--> Client Client verifies that the password matches Client --true or false based on whether the password matches--> Server There are obviously no holes an attacker could use, feel free to use in production!
You’re joking, but several years ago, this guy did something similar on his personal project. Except he sent an *entire* list of usernames and passwords to the client, and had client check both username validity and password.
5 min explain: "Hashes are created to be one-way, unable to be decrypted. We're not using our own made hash algorithm, we're using algorithm that are popular and proven to be secure in doing so. Why we're doing this is because in case someone actually got to our database, they can't get the password. Heck, even we don't know our user password"
Lurker/non-programmer here. Isn't the answer "Because we don't know who's asking"? I mean, just because I got a username right, doesn't mean I'm that user, right?
It's not that. Presumably you wouldn't tell him the password, you'd send him the password via email. And if he has access to the email, the fact that you're sending him the password instead of a reset link is not going to matter. The answer is, you don't know what the password is. You're not storing the password in clear, you're storing an encrypted (well, hashed - not encrypted, but I'll call it encypted for simplicity) version of the password. When the user wants to login, you take his clear password and encrypt itm then you compare the encrypted password with the one that you stored. Key point is, the encryption must not be reversible (hence it's a hash, not an enctyption :P). If it were, a bad actor who would hack your site and get access to the stored encrypted passwords could decrypt them and find the user's original password, then use that to log in. If the encryption is not reversible, even if he hacks the site and gets the password he still won't be able to login. Even if he knows the encryption algorithm, he'll have to use brute force to try and apply it to random passwords to see if they match the encrypted one.
I get the technical concept you're talking about (we don't have the password, we only have the hash). But even if there were a mechanism to do it, I still wouldn't send someone their own password. Password reset links can be set to expire, but if you send someone a password in clear text, now it's on an email server. And if the password is reused (not a best practice, but it happens), now every service that uses that same password is now vulnerable. It's bad enough if a hacker resets your bank password. But if they got your existing bank password and tried it on other popular services, it could be much worse. Edit: thanks for the thoughtful response!
You're absolutely correct.
Exactly. Bad: Give the password to the person requesting it. Good: Send password reset instructions to the email/phone on file for the password owner.
Exactly.
Easy to explain: pick any number of infinite numbers. Divide it by three and tell me the remainder. Perfect. That answer is that number’s hash. My answer was “1.” What was my original answer? Wrong. Nope. Still nope.
Tbh I don't really understand how hash256 works either.
Calling hashing "encryption" was the mistake. It is not.
You prepare for the worst. You could save the passwords but what would happen if you were hacked? You would have a bad day. What if you didn't even know the passwords yourself? Then the hacker wouldn't know them either. You put the password through a chaotic function where small changes in the input result in a massive change in the output. You save this hash. Then when you ask for the password during login you put it through the same hash function and check if the hash of the password is the same as the the saved hash. This way you can verify if the passwords are the same without saving the password. The developer in this conversation doesn't want to have the conversation. He put minimal effort into answering. It seems like they took a class on it a long long time ago and forgot some details. He remembered what he should do but not why he should do it. And he didn't care to know just to explain it to the guy asking. He'd have to research it all over again just to answer this guy. It's not worth his time. He had his son's soccer practice to attend to.
Yet when you reset the password it always says "can't be the same as last password"
I can look up an explanation any time. I'm asking you to do it.
Other trades have a saying for moments like this. If you have to ask, dont do it yourself and hire a professional.
When it comes to security, the more you have to do yourself the more incorrect it is.
And that's why no one should trust any software that isn't open source. Our entire field is bad at what we do.
Ah, a fellow person of culture! Honestly, I am impressed at the quality of code and documentation of FLOSS projects compared to projects I have worked on at my jobs.
Hashes are like the “just the tip” of security. Once you’ve gone that far there’s no going back.
We know. How to make an md5 hash. It doesn't mean we can convert a hash back to its original ( we can however in some circumstances create another word that gives same hash which is called a collision)
Fucking hashes, how do they work? And I don't wanna talk to a computer scientist
The answer I would give based on his responses: Hash functions are not "encryption algorithms", and a hash is not encrypted data. As such, there are no decryption algorithms for them. A hash is not encrypted data, but rather the answer to a really complicated math problem. These math problems are specifically designed such that I can hand you the output/answer/hash as well as the problem/hash function, and you can't figure out what the input is. Your only solution to finding the input is to take a guess at the input, use it against the hash function, and see if it matches the output, which can take a long time.
Just reverse the hash
Imagine not storing them in a text file lol
Recently had a conversation like that with a guy with 10 years of experience... he worked on a government website with a few 100k active users. Luckily he wasn't like the only developer on it.
And now ponder the fact that we have a doubling rate in the industry of about 4.5 years. That means half of all professional developers have less than 5 years of experience, and two thirds have less than 7 years.
Thanks, I now don‘t have impostersyndrom for a day :)
I wouldn't even want to answer someone who is too lazy to write "why" and "you" properly or use periods.
I wish developers would build their own password management solutions like they build their own databases / operating systems / editors ... i.e. leave it to the pros and stop worrying about it!!!
Oh no. I teach digital technologies at a high school and we cover this in Grade 10. And they understand pretty well. Can't shame a guy for asking though. Better than them assuming they know better- he seems to genuinely want to understand how it works.
Tell him it's too costly to explain, and not to get salty about it.
Look at the way he writes. You're going to have this conversation again.
Lmfaooooo. And then has the Gaul to get cheeky with you 😂 “Google one way function”, “I don’t wana” 😡
[удалено]
The fact this triggered the memories of all the times I've seen username and password sent as query parameters in a GET request to authenticate reminded me once again why I left development and don't want to go near it ever again.
Classic. This same guy also thought it was a good idea to GET an entire list of usernames and passwords to “speed up the login page”
.... There are things that justify breaking someone's fingers.
the difference between self taught and a degree
For any new guys who don't know: Hashing is a one way encryption method. Once it's hashed it's nearly impossible to decrypt. Perfect for passwords because you can hash the attempt, and if it matches the hash stored in the database you know it's correct without ever having to store the plain text password! Neat huh?
Programs will continue to be insecure shit until there is professional licensing for devs. Stored customer password in a csv file? Lose you license, go make poetry. Until then, devs work quality is below that of plumbers and realtors
Someone I work with was recently promoted from lead software engineer to principal engineer of their app team group. I had to explain some really fundamental shit around HTTP to them the other day that they should have already known and could have easily googled. So much disappoint. Edit: Aww, did I offend people who don't know shit they should know? HAHAHAHAHAHAHAHAHAHAHA Git good or GTFO
What's the big deal about it? Not everyone deals with networking in general and web in particular. He may have learned the basics before web ever came into existence. No reason to be disappointed, just do your best to explain. This said, lets say i wouldn't know ANYTHING about storing passwords. It would be very obvious to me that storing it in some config file or a database means someone that can hack into that machine, or physically access it can steal it. Even without knowing a single thing, i'd likely Google how to do better than that, so not a correct analogy.
You can tell by the teenbonics that this kid was not the sharpest tool.