The Legitimisation of Have I Been Pwned
troyhunt.com
troyhunt.com
I think the website should be translated, together with the domain name. Actually, "pwned" already sounds like something only those who "live and breath tech", to quote the article, would be expected to be familiar with.
This unfortunately raises a serious question of trustworthiness, with regards to phishing issues. When password.com, mypassword.net and passphrase.org are valid domain, how would you know whether to trust mypassword.com?
The bandwidth costs could also be prohibitive. To alleviate this issue, I would like to see the code being opened up (for perf. improvements), and distributed hosting encouraged, databases entrusted to a few trustworthy entities, with everything sponsored by a nonprofit entity. This doesn't solve the trustworthiness of the various entities, though [unless this is done on governments'websites?].
Of course, there is always the possibility of a rogue government/ISP/hoting service MITM the connection, even issuing false certs... But a rogue actor might as well MITM the target web site directly.
Not sure about that. I feel like translating the domain would made the phishing/trustworthiness issues more difficult - as is, there is a single canonical domain name which, at this point, has been well-publicised. Verifying that any particular translated domain for the myriad possibilities is real, especially when they may be less widely publicised/used due to having smaller userbases/fragmenting the userbase, seems tricky.
I also not sure how much of an issue "pwned" is - a lot of successful services use words that _no one_ would be familiar with or that are entirely made up.
Now since there is no red squiggly line I am wondering whether I added "pwn" as a custom addition to my local dictionary...
I work in academia and a recent weekly newsletter included an article about password security and included a link to HIBP. A few hours after the newsletter came out, we received an email from a faculty member asking what it meant that he had been "pawned" because the site said he had been.
While it got a few private chuckles from us, I felt obligated to point out that outside of our circles, most people have probably never heard the techie-slang term "pwned" in their lives.
That said, if you're still concerned there's always https://haveibeenpwned.com/OptOut
OptOut is indeed what I needed, thank you for the idea.
It's an active-directory password filter that is free for home-use and dirt-cheap otherwise.
https://github.com/JacksonVD/PwnedPasswordsDLL/blob/master/P...
I wouldn't recommend to anyone to seriously consider deploying that code in production!
Why would you not recommend code that checks the hashed password against a local DB?
See also the “pwned-passwords-django” process here: https://www.b-list.org/weblog/2018/mar/06/two-new-projects
I would. In fact that's why I have created a product to do exactly that in an efficient way...
Doing the checks online has too many drawbacks:
- availability: what do you do when the service/API is down or you can't reach it?
- determinism: what works today might not tomorrow
- security/privacy/anonymity: ...
I am just uncomfortable with naive code that makes it barely practical:
- if the dataset isn't pre-processed properly, binary searching through it won't lead to the expected results (and that's not always obvious)
- distributing a 30GB+ file on all the DCs
- binary searching through the dataset at runtime means seeking through 30GB... with a O(log n) complexity... in practice that means a very slow response time that gets exponentially worst with load.
If you pre-process the dataset you might as well do it "properly" and make it usable :p
Also maybe apply for a .well-known to HIBP file uploads?
(It's Mike from CertSimple here BTW)
> 3.2.2.4.4 Constructed Email to Domain Contact
> i) sending an email to one or more addresses created by using 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' as the local part
HIBP reports that zero of my addresses have been pwned. Which is weird because those addresses include several that have been pwned in well known cases, and several more where there's no public "We had a data breach" type report but it's clear that somebody did in fact lose all my data.
That's pretty disappointing, it suggests HIBP doesn't have very much of the breach data that really matters, and so many unsophisticated users who get to the site are probably misled.
Am I being overly cautious?
Even if you don't trust that form to behave as promised, you can do the query yourself.
https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByR...
> On average, a range search returns 478 hash suffixes
which is low enough that one could potentially try them all in a reasonable amount of time, even taking rate limiting into account.
...However, the leaks that go into the database typically contain username/password pairs, not just passwords. So if your password is in the database because your account was pwned (as opposed to the account of someone who happened to pick the same password as you), and the username is reasonably identifiable, anyone who downloaded the original leak could do the same thing, except knowing exactly which password to try rather than having to go through 478 of them!
And of course, the whole point of the password lookup is to inform you that your password is compromised and you need to stop using it. If you’re diligent, evil-Troy would only have a rather limited window to attack you before you changed your password on the relevant sites following a positive result. That is, assuming the API is honest and returns all the hashes it knows… In theory it could hold some back.
A device of any kind isn't good enough (eg. at border crossings or when lost otherwise). Biometrics can be a substitute for a user name but never for a password.
I do agree that the current schemes such as OAuth2 have odious implications. I don't think that the design space is completely explored, however. By relying solely on emailed and browser-stored tokens with judicious lifetimes, a site could outsource to email providers in a pretty secure way.
This can be applied to identity and digital ownership of any property. This solution moves security to the edges; that is, the sole owner of the property holds the keys to sign away their rights to the data through digital signatures.
This removes the need for a central authority entirely.
https://steemit.com/ethereum/@emmonspired/whitepaper-and-dem...
Don't expect it to be even semi-secret.
What if the address was only used to receive mail, not to send it?
What if a user has an email address that she does not use to send mail? She does not use this account to send mail. She does not need to send reply mail. She has other email accounts she can use if she needs to send mail. If she only shares this address with one sender, then is this not at least a "semi-private" email address?
Back in the early 1990s when email accounts started to become easy to obtain, I routinely had accounts where I only received mail. I only gave these addresses to one or a few senders. I did not use these accounts to send mail.
I do not use email as avidly as I did back then, and maybe things have changed, but I would be a little surprised if today when a user sets up a new email account she starts immediately getting email1 because "all email addresses are public", before she has given this address to anyone. The address is "semi-private" unless and until the user decides to disclose it widely. She may choose not to do that.
1 Except maybe a welcome email from an email provider.
https://leakedsource.ru seems to be up and running - or is it different people?
I mean, I sort of hate both these and prefer to just download raw data dumps straight from their source. But maybe that is legally questionable?
It's basically MD5(MD5(password)+salt). It was unclear if the salt was global to the entire DB or different for every record.
Surprise, yet another case of the blind leading the blind in PHP-land.
...
which quotes the original source, which is now down but is still available at web.archive.org: https://web.archive.org/web/20140226001727/http://blog.magic...
Additional possible info: https://www.computerworld.com/article/2476003/cybercrime-hac...
> There's a new release of PHP that adds several features, including a new sodium extension making PHP the first programming language to adopt modern cryptography in its standard library.
Surprise, yet another case of the blind leading the blind outside of PHP-land.
http://www.i-programmer.info/news/98-languages/11368-php-72-...
>"HIBP is Becoming the "Go-To" Resource for Protecting Accounts"
No "protecting" accounts" is something that is done internally at the source by companies storing user data. HIBP is offering a service that lets companies do CYA(cover your ass.) Companies can subsequently claim that they "notified" customers by telling them to check an external website. Responsibility is transferred to the customer and a third party.
>"What that means for the industry is "a rising tide lifting all boats"; it's becoming more legitimate for all those doing the right thing with the data."
No, doing the right thing with data is either protecting it or not storing it in the first place. HIPB is reactionary at best. The danger is that these companies with poor to no security practices continue to make no structural changes themselves. They simply use HIPB as a crutch do the least amount of actual work to protect data. This is supported by the following statement:
>"Oftentimes, the first a company knows of a data breach is when I send them their data."
It's hard to read that sentence and believe the author's assertion that "the industry has cleaned a lot/"