WTF Bites
-
@ben_lubar said in WTF Bites:
@Scarlet_Manuka said in WTF Bites:
They could be storing a hashed soundex / metaphone or similar. I'm not sure how well those sort of things go with numbers, but you could adapt them easily enough, and this would help stop sequences like hunter2, hunter3, hunter4....
The problem isn't that. There's a whole bunch of different similarity metrics. The problem is that they need to be able to see the current password in the clear on the server to say “this password is too similar to it”. Even if there was something that prevented that, it'd still give an attacker a strong hint whether they're close to a password for a user, greatly cutting the search effort. With proper one-way crypto-hashing, you have no such metric at all; two passwords that are one bit different (about as small a difference as it is possible to have) end up with enormously different hashes.
Yes, there has been research into encryption that lets you do similarity checks without decrypting. They're really not very safe, precisely because approximate equality tests are exactly what you shouldn't have for passwords!
The soundex of
hunter2isH536. The metaphone isHNTR. You could hash those with a strong algorithm and find similar passwords.Finding a colliding hash for a soundex/metaphone would be significantly easier than finding a colliding hash for a password, because by design, they're a fuzzy/inexact match. And it would reveal a lot about the user's password.
-
@anotherusername said in WTF Bites:
Finding a colliding hash for a soundex/metaphone would be significantly easier than finding a colliding hash for a password, because by design, they're fuzzy. And it would reveal a lot about the user's password.
You could also reversibly encrypt the soundex/metaphone of the user's last N passwords with a key derived from the user's current password.
-
@ben_lubar Ok, I "forgot" my current password... now can I reset it to the password I used before my current password?
Now I just need 2 passwords, as long as they're not too similar...
-
The problem isn't that. There's a whole bunch of different similarity metrics. The problem is that they need to be able to see the current password in the clear on the server to say “this password is too similar to it”.
No they don't. I did say a hashed soundex, should have said encrypted. Server doesn't need a plaintext soundex any more than it needs a plaintext password. The point of using soundex etc. is that you don't need to have the original available for comparison, you just compare the encrypted reduction of the new password to the encrypted reduction of the old password.
@anotherusername said in WTF Bites:
Finding a colliding hash for a soundex/metaphone would be significantly easier than finding a colliding hash for a password, because by design, they're fuzzy. And it would reveal a lot about the user's password.
Hmm, not so much because they're fuzzy as because they're short, so there aren't many possibilities to check. It's a good point that it would reveal significant information, but remember this is in the context of a function to reject passwords that are too similar to the last n passwords. I don't see how that's possible in a reasonable amount of time and storage space without storing significant information about the passwords in some form - I'm just saying that this approach would be better than storing previous passwords reversibly encrypted.
-
@ben_lubar said in WTF Bites:
You could also reversibly encrypt the soundex/metaphone of the user's last N passwords with a key derived from the user's current password.
If you're going for reversible encryption, you might as well just encrypt the actual passwords and do the similarity checking on your own. I was trying to present an approach that didn't require reversible encryption.
-
@anotherusername said in WTF Bites:
@ben_lubar Ok, I "forgot" my current password... now can I reset it to the password I used before my current password?
Now I just need 2 passwords, as long as they're not too similar...
The system won't work for password resets, but you can still definitely tell if a user is resetting their password to their current password.
-
@Scarlet_Manuka by design, a system to tell me if one password is similar to another password (without letting me know what the other password is) reveals some information about the other password, because it'll give me a hit as soon as I find a password similar to the real one, and each one that isn't a hit tells me the real password isn't even similar. And if I know what the real password is similar to, I'll be able to crack the real password much more easily.
The fact that they're short just makes it even worse.
-
@Scarlet_Manuka so, hash the concatenation of the password and the time as the complete hash, and the soundex and the time as the soundex hash, and send the time, the soundex hash, and the complete hash?
-
@Scarlet_Manuka said in WTF Bites:
@ben_lubar said in WTF Bites:
You could also reversibly encrypt the soundex/metaphone of the user's last N passwords with a key derived from the user's current password.
If you're going for reversible encryption, you might as well just encrypt the actual passwords and do the similarity checking on your own. I was trying to present an approach that didn't require reversible encryption.
The reversible encryption key in this case would be the thing the attacker is trying to get, so breaking the encryption of the soundex version would be useless as they would already have the thing they want.
-
@ben_lubar Yeah, but the whole goal was to enforce inane "password can not be too similar to previous 64 passwords"-type password requirements. A simple "password can not be too similar to old password" rule is easy because they have to enter both in order to change it.
-
@Scarlet_Manuka said in WTF Bites:
You know, you shouldn't believe those sorts of emails.
Someone remind me this week and I will tell the story. It's a pretty good one.
-
Pay the customer
clarifying as
Pay the ticket-holding customer
? This seems estimable.
Are they still at least allowed to subject the customer to a pricing schedule whose volatility would be unthinkable for any durable good (as well as for most other existing products and services)?
-
@dkf In this case, not really. But I've been at a few places now that use Active Directory, and that had a rule for "New password cannot be similar to last 3-7 passwords". In that case, I'd wager they really need to store an at least reversible form of hash or encryption to read the old passwords.
So while your remark caused everyone here to go into crypto-lala-land, didn't those AD admins just mean "New password cannot be equal to last 3-7 passwords"? Because that only requires storing the same password hashes you store for your current password for a given amount of time rather than coming up with some crazy crypto schemes.
-
I presumed the AD stored the password, or the hash the last time it was changed.
Does no one really know how it works?
This article sure isn't helpful:
Enforce password history - Windows 10
Describes the best practices, location, values, policy management, and security considerations for the Enforce password history security policy setting.
It looks like it's stored as a list of hashes:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/f6749d8e-d0d0-41ea-9f72-d5fb76c39c37/domain-password-history?forum=winserverDS
(Last post)
-
It looks like it's stored as a list of hashes:
It is. Out of the box, AD does not have any sort of "similarity" check. But a custom password filter DLL could be installed that does God knows what.
-
Does no one really know how it works?
There's a lot of 'depends' because it's very version/configuration dependant. Out-of-the-box generally, yeah, it's strong hashes protected with encryption in transit.
Bear in mind though that as @heterodox says this password similarity thing is not a native feature.If you have a local password on your machine on Windows 10 it will be stored as an un-salted MD4 hash stored encrypted with AES128 since the 2016 Anniversary Update. This is known as the NT hash and it gets stored in the SAM database.
If you have a domain account and log into a Windows 10 machine no hash is stored or cached locally, a mechanism called Kerberos handles authentication. Kerberos is bloody complicated but your password is actually stored in AD as a SHA1 hash.
During communication with the client that SHA1 hash gets slapped together with something called a HMAC for message integrity purposes and then the whole shebang gets wrapped in AES256.There's different levels of Kerberos security available too. On lower versions of windows you might drop below Kerberos and start using something called LanManager, its LM Hashes are MD5 at best, below that you drop to NT Hashes and then to plaintext.
Of course you can also mix it up in insane ways, you can ask your AD server to store the plaintext and use AES256_CTS_HMAC_SHA1_96 if you want.
Hopefully I got all of this right {of course not, one update so far}, I did just double-check with the MS docs:
https://docs.microsoft.com/en-gb/windows-server/security/kerberos/kerberos-authentication-overview
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh994565(v=ws.11)
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos
-
-
@Cursorkeys @heterodox said in WTF Bites:
It looks like it's stored as a list of hashes:
It is. Out of the box, AD does not have any sort of "similarity" check. But a custom password filter DLL could be installed that does God knows what.
But on the other hand AD does have an "equals" check at least since Windows 2000:
Enforce Password History: Enforce password history sets how frequently old passwords can be reused. This policy can be used to discourage users from changing back and forth between a set of common passwords. Windows 2000 can store up to 24 passwords for each user in the password history. By default, Windows 2000 stores one password in the password history.
From
-
Quick math test: what's 14 * 16?
...
If you answered "-32", congratulations! You're qualified to join Microchip's C18 compiler development team.
But first, someone who's already past a project deadline would like to have a word with you, regarding the two days he spent figuring out why his code was doing crazy things.
(Yes, I'm aware C18 is now obsolete. But that project was started more than 10 years ago, and I'm really not eager to discover all the marvelous new bugs they surely have introduced in the new compiler.)
-
A friend just pointed out that they actually do this on purpose:
2.7.1 Integer Promotions
ISO mandates that all arithmetic be performed at int precision or greater. By default, MPLAB C18 will perform arithmetic at the size of the largest operand, even if both operands are smaller than an int.
The ISO mandated behavior can be instated via the -Oi command-line option.
(...)
Note that this divergence also applies to constant literals. The chosen type for constant literals is the first one from the appropriate group that can represent the value of the constant without overflow.
For example:
#define A 0x10 /* A will be considered a char unless -Oi specified */
#define B 0x10 /* B will be considered a char unless -Oi specified */
#define C (A) * (B)
unsigned i;
i = C; /* ISO requires that i == 0x100, but in C18 i == 0 */
-
Unless they're computing the hashes off all the similar strings at the time of setting the password. Which is probably security-OK, but would be so ridiculously computationally- and data-expensive for even a modest deployment I'm going to hurt my nose with the force of the facepalm induced by thinking of it…
I think that significantly increases vulnerability to a dictionary attack if the 'similar string hashes' are leaked, because if one of the similar hashes is vulnerable to a dictionary attack that can then be used to attack the real hash.
@Scarlet_Manuka said in WTF Bites:
I'm just saying that this approach would be better than storing previous passwords reversibly encrypted.
And keeping your front door key under the mat is more secure than not locking the front door in the first place. It's still a bloody stupid idea.
-
@dkf In this case, not really. But I've been at a few places now that use Active Directory, and that had a rule for "New password cannot be similar to last 3-7 passwords". In that case, I'd wager they really need to store an at least reversible form of hash or encryption to read the old passwords.
So while your remark caused everyone here to go into crypto-lala-land, didn't those AD admins just mean "New password cannot be equal to last 3-7 passwords"? Because that only requires storing the same password hashes you store for your current password for a given amount of time rather than coming up with some crazy crypto schemes.
I've had AD complain for similar passwords, not the exact same ones.
-
But on the other hand AD does have an "equals" check at least since Windows 2000:
Yes. That's been mentioned about a dozen times in this thread. That does not require plaintext password storage.
-
@dkf In this case, not really. But I've been at a few places now that use Active Directory, and that had a rule for "New password cannot be similar to last 3-7 passwords". In that case, I'd wager they really need to store an at least reversible form of hash or encryption to read the old passwords.
So while your remark caused everyone here to go into crypto-lala-land, didn't those AD admins just mean "New password cannot be equal to last 3-7 passwords"? Because that only requires storing the same password hashes you store for your current password for a given amount of time rather than coming up with some crazy crypto schemes.
I've had AD complain for similar passwords, not the exact same ones.
One of these third-party products that provide that functionality mentions SHA256 and Argon2 hashing on every feature apart from 'password similarity'. So it suggests they store it as plaintext in that case. They do mention they make their own AD container and store things in attributes so it should still be as secure as AD is normally as the custom password filter runs on the AD server locally.
Sounds like these products would make it tricky to declare PCI-DSS compliance:
The PCI said:
Passwords are protected with strong cryptography during transmission and storage.
-
@Cursorkeys said in WTF Bites:
@dkf In this case, not really. But I've been at a few places now that use Active Directory, and that had a rule for "New password cannot be similar to last 3-7 passwords". In that case, I'd wager they really need to store an at least reversible form of hash or encryption to read the old passwords.
So while your remark caused everyone here to go into crypto-lala-land, didn't those AD admins just mean "New password cannot be equal to last 3-7 passwords"? Because that only requires storing the same password hashes you store for your current password for a given amount of time rather than coming up with some crazy crypto schemes.
I've had AD complain for similar passwords, not the exact same ones.
One of these third-party products that provide that functionality mentions SHA256 and Argon2 hashing on every feature apart from 'password similarity'. So it suggests they store it as plaintext in that case. They do mention they make their own AD container and store things in attributes so it should still be as secure as AD is normally as the custom password filter runs on the AD server locally.
Sounds like these products would make it tricky to declare PCI-DSS compliance:
The PCI said:
Passwords are protected with strong cryptography during transmission and storage.
Password changes shouldn't be generating that much traffic, so it should be entirely possible to store with heavy encryption. Still, even if it is encrypted, if the data is stolen there is a high chance that the key gets stolen at the same time.
And people with sufficient access to read the data directly probably also have access to the keys.
-
@Polygeekery said in WTF Bites:
To clarify that one: I paid my bill for one month but this was back when you had to mail in a check. The next bill got sent before that payment was processed so I got billed for the current charges plus the last month
It constantly amazes me how the US can be so technologically advanced and yet still use checks. For, like, anything at all.
People usually deride my very-much-German attitude of "cash is king", as I don't use my debit card when I don't see a need to / it's less than 50 bucks, and I'm skeptical of all new-fangled, useless shit like Google pay. But I can pay everything electronically that I want to. Especially bills and income happen completely automatically. I've received a check a single time in my life and felt like I'm in the 19th century all of a sudden.Anyways, hope you get the food reimbursed and looking forward to that story.
-
Today I was met with a black screen, over which was a dialog box that said the recycle bin was corrupted and would I like to empty it. However, the funny part about that was the buttons weren't clickable. They simply refused to be selected. Mousing around the screen, though, revealed an invisible text field two inches below it. This is because that was the password box on the lock screen, and this screen had appeared once I dismissed the overlay. The only way to get rid of it was typing the password in the invisible box, after which the dialog disappeared to the vortex of annoyance from whence it came.
-
First AMD came with
##ID_STRING17##and then someone came with:
Clicking it does nothing, though.
-
Why the hell are the $1, 5, 10, 20, 50 and $100 bills all the exact same colour? Get your shit together, America
-
@bb36e They're not, the MSB are similar, sure, but they differ in the LSB if you really do take the average color of the bill.
-
-
I've received a check a single time in my life and felt like I'm in the 19th century all of a sudden.
You've never published a book with a US publisher, I take it. (The charges for processing a US check at my own bank were usually larger than the amounts that the checks were for too. Grr…)
-
I've received a check a single time in my life and felt like I'm in the 19th century all of a sudden.
You've never published a book with a US publisher, I take it. (The charges for processing a US check at my own bank were usually larger than the amounts that the checks were for too. Grr…)
No I haven't. While in the states we had to actually pay rent with check (which is a bit of a catch 22 if you need to find a bank to convert your money to a check), but that wasn't handled by me directly, so I didn't count it.
Funnily enough, though, the one check I ever received was indeed for German publishing royalties.
-
@topspin it's better to pay with cashier's check. I think there are banks who don't even need you to open an account with them first.
-
Why the hell are the $1, 5, 10, 20, 50 and $100 bills all the exact same colour? Get your shit together, America
Bonus fun: $100 comes in two color variants!
-
Of course TRWTF is small silver coin being worth twice as much as big silver coin.
-
@Polygeekery said in WTF Bites:
at the end of all of that I won a motor scooter that I didn't even know I had entered a contest to win.
I'd love to hear the full story.
-
-
-
@bb36e Well you wouldn't want to walk directly to that bus stop, there's a weird dude on the sidewalk.
I find a city where there's a Whole Foods across the street from a Walmart fascinating.
-
@blakeyrat said in WTF Bites:
there's a weird dude on the sidewalk
just send him a pm when you round the corner an it's clear again
-
-
@blakeyrat said in WTF Bites:
I find a city where there's a Whole Foods across the street from a Walmart fascinating.
Technically, they're not directly across the street. The Walmart is on the side street (Showers Dr.), and there are a Subway, a pho restaurant, a nail spa, an animal hospital, and some other shops in that area that @bb36e is taking a scenic tour around between the Walmart and the Whole Paycheck. There are also a Safeway and a Trader Joe's in the same shopping center as the Walmart. The center was redeveloped a few years ago into a multi-use development with some upscale apartments and shops. Behind the Whole Paycheck is Los Altos, one of the pricier parts of town, while a few blocks northeast of Walmart are a lot of (relatively, for the area) low rent apartments, and those residents shop at the Walmart and the Target just up the street. The clientele is such that you never just pay for your stuff and walk out; there is always somebody at the exit checking receipts to make sure you actually paid for the stuff you're walking out with.
-
-
@HardwareGeek I wonder what's gotten into Google Maps, though. I remember it being rather reliable around there (after all, this is Google's backyard and all that). I also remember there being side-walks along El Camino Real...
-
@cvi looks like it thinks there is no sidewalk along El Camino Real.
Edit: "thinks" being the keyword here. Botched data collection is most likely cause.
-
Of course TRWTF is small silver coin being worth twice as much as big silver coin.
Not that Euros were that much better. Though they at least do change colour at the size discontinuities.
-
Botched data collection is most likely cause.
Yeah. Not sure if they (Google Maps) know about stuff like construction sites, could be that they think something is blocking pedestrians there, I suppose.
-
Of course TRWTF is small silver coin being worth twice as much as big silver coin.
Not that Euros were that much better. Though they at least do change colour at the size discontinuities.
And this color change make them indeed much better. Also, 10 euro cent coin says "10 euro cent".
-
Spotted just now in some other project at work (anonymized):
if (!(foo(bar) == true)) {
