Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons from a Professional Password Cracker

themarkup.org

Post reply on HN
Print view View original

111–120 of 138 posts

Re: Lessons from a Professional Password Cracker

#111

Post by yabones »

mr_mitm wrote: post #76
GoblinSlayer wrote: post #68

Earlier quoted context omitted.

And guess what, in windows networks authentication is done with domain credentials, but those are bound to your physical console, so a password manager can't be used for remote authentication in this case.

What do you mean by "domain credentials are bound to your physical console"?

Windows (in a domain environment) sends a Kerberos token for network auth which is generated on sign on and signed by a domain controller (authentication server). When the user authenticates to a network service, the token is sent to the service to validate without the need for an additional network hop to the domain controller.

Each "console" is a "seat" sort of like a PTY emulating a serial connector. Whether you're hands on keyboard or using a remote desktop connection, your login session has one kerberos ticket which is used for authentication automatically.

https://en.wikipedia.org/wiki/Kerberos_(protocol)

Re: Lessons from a Professional Password Cracker

#112

Post by hn_throwaway_99 »

bluedino wrote: post #107
tsimionescu wrote: post #60

Earlier quoted context omitted.

Are these used in conjuction, or any one will do? If it's the former, it seems like it would make the problem of loss worse. If it's the latter, then it seems you've offered a variety of ways that someone can access your systems - steal a key, copy biometrics, guess the phone password etc. - the weakest one will do.

You only need to use one. You need a PIN to use any of the devices as well.

Only needing one means you have the "lowest common denominator" of 2FA. E.g. authenticator apps are vulnerable to phishing, while FIDO keys are not. Adding FIDO key as an optional second factor doesn't really add much security if people can still be phished using a MITM attack using the authenticator TOTP.

Re: Lessons from a Professional Password Cracker

#113

Post by TheMaskedCoder »

jeroenhd wrote: post #94
dijonman2 wrote: post #23

Earlier quoted context omitted.

> The third thing is to match against specific leaks. E.g.: if you have john.smith@foo.com and there is a leak of his email and password where the password matches your records, force a password change immediately. I’ve wanted to do something similar but how would you do this without direct access to HIBP’s data? I don’t want to send customer email addresses to a third party, at least not without a contract.

For what it's worth RE: HIBP, the lookup is never actually done on an email address. If you use the API ( https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByR... , or https://api.pwnedpasswords.com/range/3E398 to see the API result), you transmit 5 characters of the SHA1 hash of the email address and check if the full hash is in the list. This makes it possible to use the API without worrying about user priva…

> you transmit 5 characters of the SHA1 hash of the email address

You don't use email addresses at all with Pwned Passwords. The documentation says "first 5 characters of a SHA-1 password hash", not email-address hash.

HIBP does not have a way to search for which password hashes are associated with a given email address, as this would be far more useful to attackers than to victims. The only data that Pwned Passwords exposes is a list of password hashes and the number of times that hash was used. The expectation is that even if that leaked password was actually for someone else's account, you still shouldn't be using it.

Re: Lessons from a Professional Password Cracker

#114

Post by mr_mitm »

yabones wrote: post #111
mr_mitm wrote: post #76

Earlier quoted context omitted.

What do you mean by "domain credentials are bound to your physical console"?

Windows (in a domain environment) sends a Kerberos token for network auth which is generated on sign on and signed by a domain controller (authentication server). When the user authenticates to a network service, the token is sent to the service to validate without the need for an additional network hop to the domain controller. Each "console" is a "seat" sort of like a PTY emulating a serial connector. Whether you'r…

Yes, I know how Kerberos works. The TGT is not bound to anything though, it can be stolen and reused elsewhere. And in the default setting, an attacker doesn't need to rely on Kerberos as an authentication mechanism, since NTLMv2 support is widely available. It's available by default.

Nevertheless, did GP mean Kerberos tickets by "domain credentials"? How does Kerberos prevent the use of password managers? I'm confused.

Re: Lessons from a Professional Password Cracker

#115

Post by yrro »

jiggawatts wrote: post #7

Some rules of thumb: All Windows passwords shorter than about 10 characters shouldn't be considered secure, as the NT Hash at this point is so easily reversible that it's basically a "light obfuscation" at best. A single GPU can crack all 8-character passwords in minutes. The single best security setting on a Windows network is to increase the minimum password length to something like 14 characters. Use 20+ for privi…

Can a Windows expert chime in here. Why is the NT hash even calculated any more? Is it still the default? Can group policy be configured to tell everything to not used to disable NTLM everywhere? And can't AD be configured to disable RC4 everywhere? Do MS ever plan to properly deprecate NTLM/RC4, disable it in new domains and start displaying prominent warnings when they're enabled?

Re: Lessons from a Professional Password Cracker

#116

Post by GoblinSlayer »

mr_mitm wrote: post #76
GoblinSlayer wrote: post #68

Earlier quoted context omitted.

And guess what, in windows networks authentication is done with domain credentials, but those are bound to your physical console, so a password manager can't be used for remote authentication in this case.

What do you mean by "domain credentials are bound to your physical console"?

When you log into the system, a keyboard is usually the only device you have to enter the password, unless you store in on paper or on a second device. And even if you store it on paper and the password is long, some operations like lock screen (that can be also misconfigured by domain admin) become expensive and thus impractical.

Re: Lessons from a Professional Password Cracker

#117

Post by vladvasiliu »

themoonisachees wrote: post #109
vladvasiliu wrote: post #88

Earlier quoted context omitted.

I think it's only turned on when you connect it to an online account. It's still possible to only use a local one, but it's in an unexpected place, so I expect most people to go the online route.

indeed, only when using a microsoft account, which by the way is now required in the latest isos. you can still bypass it but it requires being offline for the install. that being said, there are still many laptops with older windows version preinstalled that do not have the requirement; however users that don't care about this will just click the MS account option because the button was kind of hidden. their reason…

It's actually still there and no need to be offline. Tested this the other with a brand new win11 22h2 install drive.

The workaround is to click "connect to my work account", then "domain join". Not Azure AD, but regular AD. This then presents you with the classic offline account creation dialog. It doesn't even ask you what the domain is.

Re: Lessons from a Professional Password Cracker

#118

Post by BeFlatXIII »

ovi256 wrote: post #90
ollifi wrote: post #45

Earlier quoted context omitted.

I sort of wish companies would not have employees passwords. Hashing should be standard practice.

It must be, but publishing old passwords can still be done by saving the old cleartext password on password change.

As in store "old password" as cleartext on its final use?

Re: Lessons from a Professional Password Cracker

#119

Post by GoblinSlayer »

yrro wrote: post #115
jiggawatts wrote: post #7

Some rules of thumb: All Windows passwords shorter than about 10 characters shouldn't be considered secure, as the NT Hash at this point is so easily reversible that it's basically a "light obfuscation" at best. A single GPU can crack all 8-character passwords in minutes. The single best security setting on a Windows network is to increase the minimum password length to something like 14 characters. Use 20+ for privi…

Can a Windows expert chime in here. Why is the NT hash even calculated any more? Is it still the default? Can group policy be configured to tell everything to not used to disable NTLM everywhere? And can't AD be configured to disable RC4 everywhere? Do MS ever plan to properly deprecate NTLM/RC4, disable it in new domains and start displaying prominent warnings when they're enabled?

It's a GPGPU offline attack against a hash that can be recovered from a turned off system. So is only realistically useful to learn your password habits. I once cracked my forgotten password this way.

Re: Lessons from a Professional Password Cracker

#120

Post by mr_mitm »

GoblinSlayer wrote: post #116
mr_mitm wrote: post #76

Earlier quoted context omitted.

What do you mean by "domain credentials are bound to your physical console"?

When you log into the system, a keyboard is usually the only device you have to enter the password, unless you store in on paper or on a second device. And even if you store it on paper and the password is long, some operations like lock screen (that can be also misconfigured by domain admin) become expensive and thus impractical.

Sure. That's why I recommended password managers only for high privilege accounts. Passwords of those accounts should almost never be typed on a keyboard. They can be looked up by authorized personnel who logged on first with their low privilege account.
Post reply on HN