royce

The rest of the snark/ bitterness aside ... NTP takes latency as a constraint, and accommodates for it.

And far from a disgrace, NTP was a brilliant design for its time, and has proven to be far more future-proof than should have been expected.

Someone seems to have dropped the "EXCEPT EUROPA" part. ;)

I work in telco, too - by my read, they're not disagreeing:

  Although Diameter was intended to replace RADIUS, the
  protocol itself offers no security when used over TCP. As a
  result, RFC 6733 suggests that Diameter messages should
  be secured using TLS or DTLS; 5G has replaced Diameter
  with signaling over HTTP/2 [30].

"5G completely replaced DIAMETER with signaling over HTTP/2. DIAMETER is only used in legacy systems that has not yet been updated. Early 5G can be deployed as Non-standalone (NSA) or standalone (SA). NSA means a 4G core with 5G radio while SA means both 5G core and 5G radio. NSA has a lot of severe limitations. Many networks are already SA and the rest are working on rolling out SA."

The paper https://www.blastradius.fail/pdf/radius.pdf) explicitly states DIAMETER "never replaced RADIUS for many common use cases" and "the protocol itself offers no security when used over TCP". So unless the DIAMETER traffic is isolated or tunneled, it's arguably less secure than RADIUS/TLS.

CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3596

Nothing on oss-security list yet, but it'll appear here: https://www.openwall.com/lists/oss-security/2024/07/09/

Essential reading is this FAQ from DeKok, FreeRADIUS maintainer who revised the RADIUS UDP approach to mitigate: https://www.inkbridgenetworks.com/blastradius/faq

Naively, would there be any value in providing an RSS feed of new adds, date changes, etc. ?

"[PATCH] socks: return error if hostname too long for remote resolve

Prior to this change the state machine attempted to change the remote resolve to a local resolve if the hostname was longer than 255 characters. Unfortunately that did not work as intended and caused a security issue."

That's an entirely different threat model. hotpotamus is right - the article, and the threat model, are about offline attack of back-end password hashes, after they've been stolen or leaked. The speeds against fast hashes are indeed measured in the billions or trillions on ordinary commodity hardware.

Further, password hashes are not "decrypted" - they are cracked, because it's not reversing anything - https://www.techsolvency.com/passwords/dehashing-reversing-d... (disclaimer: my explainer)

Being able to firmly reject all unauthenticated messages is still the target end state. The risk of a threat actor sending an email that looks completely legit, and simply asking the user to "check their spam folder", is very real.

Site author here. Thanks for helping to get the word out - every bit may help someone.

While I consider my page to provide useful color, and I validate and summarize and cache info updates locally to add value ... it won't scale for long. It's really a stopgap - to buy defenders time until better efforts emerge.

A few efforts likely to become higher leverage than mine, because they can be driven by pull requests:

* https://github.com/NCSC-NL/log4shell - already quite comprehensive

* Whatever CISA may spin up - https://github.com/cisagov/log4j-affected-db

* Kevin Beaumont (@GossiTheDog) - turns out he worked with CISA on this

That being said, I'll keep working on mine as long as it still provides value; updates/corrections welcome.

Am I the only one who thinks this sounds a lot like how pyramid schemes work?

It's now been cracked - and now we know why it took so long:

https://minnie.tuhs.org/pipermail/tuhs/2019-October/019124.h...

It depends on the organization. Some larger financial institutions are sometimes more likely - or even bound by internal policy - to simply trigger their standard card-cancellation procedures.

Instead, one could present the financial institution with the hypothetical question, and then only give the specifics if the institution's policies are non-destructive.

If the finder is a decent sort, and has the time to try alternatives, I'd rather get the cards back intact than to have to do the cancellation dance.

Or Alaska or Hawaii - same problem (shipping restrictions invisible until checkout). It's insane. They know exactly where I live.

The superset of all of the original CSRG-shipped cracking-eligible descrypt hashes is actually about 1400 hashes, drawn from a slightly smaller number of overlapping accounts among releases. Many of them appear to have been temp/test/throwaway with generic usernames and short, simple passwords.

I'm startled that there's no mention of app whitelisting yet.

Code signing reduces ops overhead and latency in environments that are using app whitelisting.

If the code is signed, then the signing certificate can be trusted once. All upgrades and patches that are signed with that certificate can be automatically whitelisted, with no intervention from teams managing the whitelisting.

But if the code isn't signed, then if even a single byte changes in the executable, it must be re-whitelisted - usually manually.

The more signed apps there are, the easier it is for companies to start using application whitelisting, the fewer people are needed to maintain it, and the faster patches to those applications can be deployed. Making it easier for companies to move to whitelisting increases security for the ecosystem in the aggregate.

Yep, that was exactly why (or at least, very strong circumstantial evidence):

https://productforums.google.com/d/msg/websearch/H4XbbwWmtAY...

I don't think it was ever officially announced/admitted anywhere, though. But it was exactly around the time that Google+ was rolled out.

Now that Google+ is going away, can we have the +string operator back in Google Search, to force inclusion of a single string (instead of having to use double quotes)?

For us (early regional ISP, mid-'90s), a lack of separate per-service hostnames caused significant scaling fragility.

In the initial rollout, all services were served from a single physical host with just one listening IP, which the bare 'example.net' resolved to. (Was this naive of us? You bet.) Other service hostnames (www., smtp., etc) were all just either CNAMEs to that hostname, or A records to that IP.

When our SMTP usage started to exceed the capacity of that single host, we tried to move 'smtp.example.net' to a different host. This is when we we discovered that many users were configured to use 'example.net' for SMTP instead. We had to update all of those users' configs before we could turn down SMTP on the original host. (We couldn't afford big-iron load balancers, and they were less common then - we just used DNS round-robin for load distribution).

At that point, we realized that customers were using bare "example.net" for everything - homepage, SMTP, POP3, IMAP, FTP, DNS, shell access - you name it. It was easy to remember - and it worked. So it was hard-coded everywhere - FTP scripts, non-dynamic DNS settings, etc. And this was looong before email clients had automatic configuration detection, so that was all hard-coded, too.

So we had to painfully track down all the users who were still hitting 'example.net' for SMTP, and help them update their configs before we could turn down SMTP on the original ancient host. The other services had to go through a similar painful transition.

We concluded that the only way to prevent this from happening again was to make sure that the bare hostname never offered any services at all - except for a single HTTP service whose sole purpose was to redirect 'example.net' to 'www.example.net'.

From then on, each new vISP domain had the same non-overlapping service namespace ... so that the otherwise inevitable configuration drift would be impossible.

Later, with the rise of things like email autoconfiguration, load balancers, and POP/IMAP multiplexors (like 'smunge'), we had more options. But at the time, avoiding services on 'example.net' was the only way to go (for us). Having a bare 'example.com' as the sole hostname in the browser bar was a sign of brokenness. :)

If someone is developing web applications in such a way that they need support from their browser vendor to make them work properly ... they're doing it wrong.

What about the other case - when they're not random, but also not reused ... such that the psychology of the user's password-selection methodology might be exposed?

Just because the horse is out of the barn doesn't mean that the owner of the barn knows about it yet.

What does that buy you, if they are in plain text?

Nothing. That's why I was agreeing with you for that subset.

But N may be smaller than you might think, when frequency data is also supplied by the API.

https://gist.github.com/roycewilliams/60b77640a962125b04ae67...

Shadowed password files may as well store passwords in cleartext; if those passwords are not reused anywhere, the situation is safe

Wait, what?

If they were randomly generated and of sufficient length, yes.

If they weren't randomly generated, even if not exactly reused, they are very likely to reveal the psychology of that user's password selection habits. This is of definite value to a focused attacker. Not only could it inform guessing passwords on other systems, it could also inform guessing that user's _next_ password on _this_ system.

They don't need to crack your password to gain any more access to that same site.

Just because they have the hashes doesn't mean that they have other access. Hash lists are bought, sold, traded, and stolen all the time. Someone who possesses that particular hash may be multiple hops away from the group that originally acquired them.

Also, just because the database layer that the passwords are stored in is owned, does not mean that a particular target level of access has been acquired. Password storage can be abstracted into an entirely standalone subsystem, for which knowing, say, an admin of that system's password would be quite valuable.

Random passphrases are indeed a good idea. XKCD #936 advocates for 4 words randomly selected from a 6000-word dictionary, which is 6000^4, or ~1.296 × 10^15, which isn't actually that strong if the service in question has chosen a weak password hashing algorithm. When using pure bruteforce or masks (not a dictionary or hybrid attack) against a large-ish corpus of passwords (say, a few million) a system with 6 GTX 1080s can realistically try 8.2 billion SHA1-hashed passwords per second, which would exhaust the entire XKCD 936 keyspace in about 45 hours. (If you bump it up to five words from a 20,000 word dictionary, you get ~3.2x10^21 possibilities, which is better.). And if you focus on a single hash, that SHA1 rate jumps to ~32 billion hashes per second, which would take less than 15 hours.

At that speed, processing the entire Pwned Passwords list would almost take longer to read from disk and into memory than it would take to exhaust against a single password. Password cracking specialists would of course try raw wordlists first (And therefore "more useful", in a way) ... but we many other tools in their arsenal that generate far more than a half a billion candidate passwords. And at that rate, you can exhaust all 8-character passwords made up of printable ASCII - 95^8, ~6x10^15 - in a couple of days. Other techniques (mask, hybrid, rules) can achieve similar rates, and combinator attacks are slower but still pretty efficient.

By contrast, attacking bcrypt cost 12 on the same system can only try ~660 hashes per second - against a single hash. At that rate, if you just tell the attacker "it's somewhere in the Pwned Passwords list", it would take about 210 hours to exhaust the raw list, and 36 years to exhaust all 6-character passwords made up of printable ASCII.

In other words, if a service is storing passwords poorly, that service should be fixing that long before they should be trying to blacklist a half billion passwords. The purpose of blacklisting up front in the password-changing UI isn't to forbid a half-billion passwords. It's a way to reduce risk of online attack - and an opportunity to guide users towards better selection methods. There's a reason why Dropbox only blacklists the top 30K.

I'm quite familiar with password attack scenarios.

If high-value targets are selecting passwords that would be vulnerable to a targeted cracking attack, the solution isn't to blacklist a half-billion passwords (when they could just as easily come up with literally trillions of other passwords that would also be bad, yet are not included in the blacklist). The solution is to show them how to manage their specialized threat model - 2FA, creating strong passphrases, using a password manager, etc.

A combination of public leaks and private contributions. He does a pretty good job of vetting them and determining what era they're from (by polling some users to see when that password was used/changed on that service, etc.)

Because:

1) In an online attack, against a properly-configured service, even if password spraying is used, only the first few thousand passwords can be tried before rate-limiting, CAPTCHAs, etc. kick in.

Would a user with a known leaked password at a different site be vulnerable to an online correlation attack? Yes. And that's why some big services supplement their approach by proactively searching for those leaks and forcing a password reset for those specific users.

2) In an offline attack, when the passwords are properly hashed with a modern slow hash, even an expensive GPU or FPGA cluster would take weeks to exhaust a 10,000 word dictionary against a large user corpus, and a significant amount of time even when a single user is targeted.

Would users with '123456' get cracked pretty quickly? Yes. And that's why the top X are forbidden - to make offline attackers have to dig deeper into their wordlists (and thereby also their pocketbooks) to crack a password in a useful amount of time.

The ranking in Troy's list is based entirely on how common the words are. Here are the top 10, with their relative frequency:

  c4a8d09ca3762af61e59520943dc26494f8941b:123456 (20760336)
  f7c3bc1d808e04732adf679965ccc34ca7ae3441:123456789 (7016669)
  b1b3773a05c0ed0176787a4f1574ff0075f7521e:qwerty (3599486)
  5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8:password (3303003)
  3d4f2bf07dc1be38b20cd6e46949a1071f9d0e3d:111111 (2900049)
  7c222fb2927d828af22f592134e8932480637c0d:12345678 (2680521)
  6367c48dd193d56ea7b0baad25b19455e529f5ee:abc123 (2670319)
  e38ad214943daad1d64c102faec29de4afe9da3d:password1 (2310111)
  20eabe5d64b0e216796e834f52d61fd0b70332fc:1234567 (2298084)
  8cb2237d0679ca88db6464eac60da96345513964:12345 (2088998)

  $ for topx in 1 100 1000 5000 10000 20000 50000 100000 200000 500000 1000000; do \
    echo -n "$topx: "; head -n ${topx} pwned-passwords-2.0.txt | tail -1; 
  done

  1: 7C4A8D09CA3762AF61E59520943DC26494F8941B:20760336
  100: 482FA19D5C487CB69ACDA19EEE861CC69D82CC94:272371
  1000: 5B9FE558F673D63309BEB13BFA5DA6C30A3CA1BF:64912
  5000: FE648FC459A6F6EF6CD347BEE3D494766239BBB5:19860
  10000: 2682A3DBA7A1452EE7EE9980F195C6A768055DA6:11055
  20000: 53490A3C8567342B57B6A4FF24908DF73182B357:6309
  50000: 7517CD23A308BBCD05E5AD24AA6AD054237ED470:3153
  100000: BA6D6A41B9548C523833627A8B0E5170558BE1EA:1752
  200000: E50E6893264519636E90E95B6B1A85D0A691E0B1:931
  500000: AF8DF653177BBB3FEE2DA68D314B94CB5281B4F3:381
  1000000: BDD57A4CAA691A3441C1190C6F087B58B2EE3EF6:186
  2000000: C824AF24AA8F2FD99AD6842DC0E4B49100D96161:93
  10000000: 352DB7177AB7848DF1C102234401097FE40EB87D:22

So ... based on this data ... what is a reasonable value for that count, such that if the value is exceeded, the user should be disallowed from using the password? How much real-world online or offline resistance is provided by disallowing, say, passwords used at least 186 times in the corpus (roughly a million passwords, though 5201 passwords are at the 186 mark)? (The answer should be self-evident; if it isn't, I can provide more background).

Put another way ... if the corpus was only 1M in size, those right-hand values would be much smaller. How could you determine the threshold then? What I'm trying to illustrate here is that it's not the absolute value of that commonality number that matters; it's the relative rank. But that relative rank can't be determined via the API; you must analyze the entire corpus directly - and then discard the vast majority of it for blacklisting purposes.

I totally get that the threshold might vary per implementation. But it varies much less once the hash is slow enough, and the authentication service is suitable rate-limited. In other words, any system that would get real benefit from a 1-million-word blacklist is one that needs to be improved elsewhere instead.

But Troy didn't provide any guidance about that, or even how to judge for yourself what the threshold might be. He just provided an API to blacklist a corpus of passwords that is three orders of magnitude larger than a properly designed system would ever need.

1. https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-pass...

Some large services do use the actual dumps, and correlate them with the email address associated with the current user, in order to give users a personalized warning that they're reusing a leaked password that's already associated with that specific email address. This is a much different proposition from forbidding that specific user from using a half a billion passwords.

A full 80% of the v1 corpus can be avoided by simply requiring a minimum password length of 12. As Troy has pointed out elsewhere, this wouldn't be great UX, either. While it would dramatically increase the chances that they came up with a word that would be A) not in the existing blacklist, and B) harder to attack offline ... it would still be significantly bad UX compared to the best-practice alternative that I lay out in a separate thread branch.

But it would still be much better UX than use of the full blacklist.