If the hashing is done on the client and then sent to the server, then the server is effectively just processing as a plaintext password. If an attacker gets hold of the server password database, then they can just connect to the server and pretend to be the client and hand it the hashed password that they read from the database breach.
If you hash the password on the server instead, then if the password database is breached, then an attacker needs to actually reverse the hash[0] and find the original password in order to log in, because that's all that the server will accept.
[0] Note, this should be difficult[1]
[1] In crypto, "difficult" should mean "impossible before the end of the universe"
No it's not. Did you ever think that you can hash something twice? Hash it once on the client, then hash and salt it server side, like normal. It means that the server never actually knows your password, but that's about all it gives you.
> It means that the server never actually knows your password
If the client is hashing it without a salt the server could simply check a Rainbow table (https://en.wikipedia.org/wiki/Rainbow_table) to know which password it is. For short inputs this could be trivial.
Sure, but I still think this is preferable to sending the password in clear text even over HTTPS. You're trusting the server doesn't do anything with the password and immediately hashes it, but it might not. It might store it, or even if it doesn't, your password will stick around in RAM for an indeterminate amount of time.
If the server is compromised in any way, passwords could be exfiltrated. Companies are, sometimes, wildly incompetent. Zoom historically stored private keys on the same server as their "encrypted" data. I would not be surprised if your password is just stored for "convenience" or some other bullshit reason and just waiting to be breached.
> Sure, but I still think this is preferable to sending the password in clear text even over HTTPS. You're trusting the server doesn't do anything with the password
My point is in both cases the server has access to the password. As I mentioned, without salt the server can get the original password (by checking the pre-computed rainbow table of hashes up to n length), so the trust issue is the same.
If this is slightly better (more obfuscated) or the same thing + a false sense of security is debatable, but I could agree.
Well no, because rainbow tables are quite small. You don't have precomputed hashes for all passwords 24 characters and under that contain numbers and symbols.
I mean, even with just letters, you're looking at 620448401733239439360000 hashes required. x 128 / 8 bytes, you're looking at ~ 9000 zettabytes. So, a few order of magnitude larger than the entire internet.
If you have a strong password, it's not comparable. In scenario one the server has the password immediately. In scenario two, it would require the heat death of the universe to precompute the hash to find out the password.
Very interesting point. I did not think of that, thanks. I was looking at the speed of calculation in different scenarios (calculated on the fly)based on which characters are part of the password and it is still very difficult, if you have a strong password. I am curious which percentage one could match just checking for hashes of common passwords, or common patterns like exclamation marks at the end. In any case it is better than the unhashed version, I agree.
This. You also don't really need Pydantic unless you're de/serializing data from external sources. A dataclass is perfectly cromulent if you're just passing around data internally.
...by being as shockingly contrasting with their environment as possible. Maybe your aesthetics differ, but I find it quite ugly. If it wasn't, it wouldn't grab my attention so well. Wearing something shockingly ugly is a great way to not be mistaken for a deer.
By contrast, I find a well camouflaged deer quite beautiful--once I notice it at all. The beauty comes from the way that it is so clearly a thing of its surroundings. Nothing at all like a bright orange hat.
> Wearing something shockingly ugly is a great way to not be mistaken for a deer.
Sure... yes the bright orange is ugly, but it's not the ugliness that prevents you from getting shot, it's the bright unnatural color. Other hunters aren't thinking "oh that's really ugly, it must not be something I can shoot" they're thinking "bright orange means person, I should not fire my rifle in that direction".
> If it wasn't, it wouldn't grab my attention so well.
Are you saying that if you thought the bright orange was pretty it wouldn't occur to you not to fire your gun in its direction?
If I thought that bright orange was a part of a healthy forest ecosystem, I would likely see beauty in it. And if my intent was to shoot denizens of such an ecosystem, then yeah bright orange would make a poor indicator for "don't shoot here". You'd be better off with something ugly, something which clearly doesn't belong.
> Obviously I know I could name this function and feed it in, but for one-off logic like this I feel a lambda is descriptive enough and I like that it can be done in-place.
FWIW, you'd also have the benefit of being able to unit test your logic.
I mean, maybe, that's why your lambdas shouldn't be too long.
I have done a lot of Haskell and F#, and I'm very familiar with the concept of "lifting", and yeah being able to individually test the components is nice, but even within Haskell it's not too uncommon to use a lambda if the logic doesn't really need to be reused or is only a couple lines.
If you have a huge function, or you think there's any chance of the logic being reused, of course don't use a lambda, use a named function. I'm just saying that sometimes stuff that has 2-4 lines is still not worthy of having a name.
My first car was a 1992 Oldsmobile Cutlass Supreme S, which I got in 2010 and drove for three years before it bit the dust. It was an absolute boat but it was fun to drive, and I could see virtually 360°. I never once in the time I had it had any vision issues.
My next car I got in 2021 was a 2007 Prius. It has a super thick A-pillar in a really terrible spot that makes turning left quite stressful. The turning radius is amazing and I love driving what these days is considered a "compact car", but I absolutely loathe the A-pillar. I am constantly dancing in my seat to see around it, and will check both ways 4 or 5 times before crossing roads from a side street because my field of view is so limited.
I've always mused about whether reducing vision for the sake of crash safety actually ends up resulting in more accidents. Is it better to try to prevent accidents by improving visibility or mitigate harm in the event of an accident (which seems more and more like an inevitability these days where I live where there's virtually zero traffic enforcement; I see red-light runners multiple times per day, and a section of our city highway with 55 mph speed limit has the entire traffic stream going 75)?
I could talk for days about the design of modern cars in the US...
Old-fashioned-guidebooks, like the other commenter said, can be useful... but IMO it's a gamble.
One option if you're looking to avoid Kyoto, but want something that still feels sufficiently old world, is Kanazawa. You can take the Shinkansen from Tokyo to get there; ever since this line was opened it also has its fair share of tourists, but it's way less popular than Kyoto and IMO very nice. Old Samurai town out on the western coast of Japan.
If you want history that's more somber, and you're already visiting Osaka, just take the Shinkansen a bit further down to Hiroshima. The atomic bomb museum there is IMO required viewing for seeing and understanding the impact those events had. The Nagasaki one was even more powerful of an exhibit, but frankly to go to Nagasaki you need to fly (a Shinkansen exists but it's not a fully connected route at this time).
I'm out drinking at the moment so I'm not about to write a novel, but whenever you go to book your stuff you can feel free to email me (should be in my profile) and I'd be happy to help figure things out. People should visit Japan - I don't ever want to gatekeep it; I just think people should avoid chasing the same beaten path. :)
Buy an old-fashioned guide book instead of using the internet, the consumer parts of which are an advertising machine that inexorably trends towards the lowest common denominator.
... if you're a full-time traveler that can afford to stay for months at a time. For the rest (the vast majority) of us, the GP comment is what we get.
The whole tone of TFA is super frustrating. The original story is funny, well written, and, well, a story meant to be told "over drinks at a conference". TFA misses all the humor and generally seems to be written by a very bitter person.
Forgive my ignorance, but what's wrong with this one?