3 ms·
For those privacy focused, here's how you can remove your information from their public search ability. https://haveibeenpwned.com/OptOut https://haveibeenpwne
by moose44 3y ago
For those privacy focused, here's how you can remove your information from their public search ability.
https://haveibeenpwned.com/OptOut https://haveibeenpwned.com/OptOut
- layer8 3y agoYou have to solve a Google ReCaptcha though, which privacy-focused folks won’t like. Also, just FYI, “The controller of the domain your email address is on will still see you in domain searches.”
- randunel 3y agoTo merely use the service, you have to solve a seemingly infinite cycle of hcaptchas from cloudflare, this recaptcha is much more decent to users from 3rd world countries!
- deleted 3y ago[deleted]
- ziddoap 3y agoSeems slightly useless to opt-out of HIBP when your email is still in Collection #1 or Anti Public Combo List or whatever. Anyone wanting to do something nefarious with the emails will surely download the full source lists rather than try and scrape the aggregation site.
- blibble 3y agohe's become a very tempting target in himself that gets more tempting with each additional database added I wonder if he actually deletes the data...
- toomuchtodo 3y agoThis is a call for service providers in these dumps to move to Passkeys faster, not for the data to be redacted or censored. You want to decay the value of the credentials as rapidly as possible once exposure has been determined. This aligns with NIST guidance around secrets rotation. Once a breach is determined, all of these passwords should be invalidated immediately and require a password reset if you're so behind you're not offering Passkeys or SSO. Rate limiting will slow credential spraying attacks, but the only way to eliminate them is to use SSO ("Login with") or Passkeys. You are negligent as a provider if you are not invalidating leaked credentials in a timely manner. https://pages.nist.gov/800-63-FAQ/#q-b05 https://pages.nist.gov/800-63-FAQ/#q-b05 > “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.” > Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.
- prepend 3y ago> This is a call for service providers in these dumps to move to Passkeys faster Does it really matter? I think all of my accounts use 20char autogenerated passwords from google that are unique for each account. So if one is breached, it’s just breached. Seems to have the same protection as a passkey.
- toomuchtodo 3y agoYou are the outlier. This is not the norm. Passkeys do this for the broad public, with the keys backed up to ecosystem cloud storage and defended by strong security systems at Apple and Google. Lets not argue passkey sovereignty in this thread, there are efforts ongoing to make them exportable so you can manage them in password managers. I agree it is a valid concern to prevent ecosystems holding users hostage. Long strings in password managers was a shim until Passkeys got here, because passwords suck. This is a well worn path in enterprise with PKI. Passkeys are PKI for the Average Joe. Folks here will always have esoteric auth use cases, but you design for the average on this topic (consumer auth). https://passkeys.directory/ https://passkeys.directory/ https://passkeys.2fa.directory/us/ https://passkeys.2fa.directory/us/ https://bitwarden.com/blog/a-closer-look-at-password-statistics/ https://bitwarden.com/blog/a-closer-look-at-password-statist... > 19% of respondents said they used “password” as their password (!!!) > 52% use easily identifiable information in their passwords, such as company/brand names, well-known song lyrics, pet names, and names of loved ones > Best practices are still diluted by bad habits, with 85% reusing passwords across multiple sites and 58% relying on memory for their passwords > A majority (68%) of respondents manage passwords for 10+ sites or apps and yet 84% of respondents reuse passwords > More than half of respondents forget and reset their passwords on a regular basis > Around a quarter (20%) were affected by breaches and a majority (80%) were prompted to reset their passwords > Over half (56%) are excited about passwordless options, and 50% are using or would use ‘something you are’ forms of passwordless authentication
- c0nfused 3y agoAs someone who is not at all excited about passkeys, I think they are just moving the average user into an existing enterprise. The enterprise being whatever Big Tech Company you trust the most. Then you gotta pass through one of the "trustworthy" tech companies to access anything, which is simultaneously great and also a huge ask as most of them are data vacuums.
- sunnybeetroot 3y agoWouldn’t it be hashed?
- Sephr 3y agoDo they have a domain-level opt-out?