And miss “scud-Sucker07_1”.
There’s a combinatorically-large number of passwords that are “similar” to any given password. There’s no way to check all of them.
The way password-based authentication is supposed to work, the verifier learns from the prover that either (a) they know the password; or (b) they do not know the password. Nothing else: not the actual password, not the MD5 hash of the password, nothing.
Absolutely, although you should check forum rules if we’re allowed to post about how to exploit deficiencies in computer systems.
The password system developers can’t stop all bad password habits, but they can easily stop some of them. People only very occasionally change their password, so the overall computational budget to do various combinatoric sweeps is not costly.
The app which asks you to choose a password in the first place can check, when you type it in, whether or not it is “weak” and warn you or refuse to accept it, but the server cannot because it is never supposed to know your password in the first place.
We’re talking about the layer that computes the hash of the plaintext of a proposed password, and then compares to hashes of previous passwords. That same layer can also compare variants of the plaintext, in order to test for limited cases of password reuse.
The layer where you type your password, or reads hashes of your password, could store hashes of your password, or the password itself, but that is arguably a security hole, is what I meant.
I’m not talking about storage, but where things are compared.
Where what is compared? I am thinking of an application like where I have a laptop running a web browser, and I want to access the bank’s server with a password (possibly as one of several “factors”, but that is not relevant). If they actually follow the relevant standards for password-based public-key cryptography, the bank never, ever learns my password or any hash thereof, so they have nothing to compare. Only my laptop might be storing the password (after all, it gets typed in there) and could then compare things if/when I change it.
Somewhere in the authentication chain there is one spot that compares a hash of the inputted password to a hash of the actual password. This would be done in protected, volatile memory. And it may not be a direct hash, but an encrypted hash, so that that spot cannot determine either the plaintexts or stored hashes. But there is that one layer which determines if the passwords match.
When a user inputs a new password, that same location can compare variants of the proposed password as well, by request of the piece that is handling the plaintext. This allows the system as a whole to reject passwords that are too close (for some limited definitions of close) to a previous password. All without doing plaintext comparisons of the old and proposed passwords, nor storing them.
Not in the secure password protocols described in IEEE 1363.2 or RFC 2945 or related methods. Ideally, knowing the password is a zero-knowledge proof.
Hence:
That is exactly right, and if I “change” the password by re-using the same one, they will never know since the new encrypted hash will be generated using a different random salt.
The part of the system that changes the plaintext password into a hash necessarily knows the correct salt.
It does. It is chosen when generating the password. The layer where you type in your raw password (e.g., your computer/web browser/terminal) could indeed theoretically store your password or hashes thereof; maybe some users want that (password manager)?
If that layer is separate and not compromised, then the rest of the system does not learn anything about your password. But, yes, we are working under the assumption you are checking the Post-It note and typing it in somewhere.
Re: car batteries
My '63 beetle had it’s 6V battery under the rear seat. When the battery died typically you push-started it until you replaced the battery. My wife’s 2001 Cadillac DTS had the battery under the back seat cushion. It was VERY heavy as I recall when it died and I had to replace it
OK. This takes the cake.
Bought a new house. The oven is an LG. Fine. Heat it up start cooking, and then open the door to see how things look. Close the door.
The oven turns OFF if you open the door. Just because you wanted a peak at things. I come back a half hour later and the oven is OFF.
Makes for some late night dinners. GRRRR.
Oh, and I have to enter ‘Cook time’. I’m the damn cook, I’ll take care of that.
That’s gotta be a bug and/or wiring issue. That can’t possibly have been purposely designed into the stove.
Having to enter a cook time is odd as well.
What’s the model? I almost wonder if there’s an incorrect setting. Like it’s in Sabbath mode or something.
Out of curiosity, what happens if you turn the oven light on? I’m wondering if something to do with opening the door is making the motherboard glitch and reset?
ETA, I know manually turning the light on isn’t the same as opening the door, but it’s an easy first step and at least some of the same wiring will be energized
Thanks, I donno. I just moved here and am getting used to this weirdo oven. But thanks. I’m betting it’s a ‘safety’ feature.
At least it didn’t ask for the square root of 5,832.