All your web viewing habits
are belong to M$.
Microsoft has detailed how the Password Monitor feature in Edge works after it pushed version 88 of the browser into the Stable channel. The release follows the recent first anniversary of Chromium-based Edge emerging from preview. The Password Monitor feature was rolled out in an update tilted towards "transparency and …
What am I missing? I have been writing software for decades that only stores a hash of the passwords given it, and when the user inputs a password to gain access, the hash of the candidate password is compared to the hash of the real password. This has been standard practice everywhere I have worked since the dawn of time. This is considered new & innovative?
This post has been deleted by its author
I think the distinction is that you are hashing the password provided, before the comparison (otherwise thats essentially a plain text password with less entropy). MS are claiming they can send the hash off to check it against a list (haveibeenpwnd, probably!) without downloading the whole list to every browser, and without sending specific hashes off which, if discovered, then whittle down your known list of passwords. Quite why all this palava is better than an HTTPS API against the source, I dont know. I can only assume they don't want to pay Troy Hunt to increase his request limits and they want to show off!
Erm, unless I'm missing something, hasn't Firefox been doing something like this with email addresses for two and a half years? And haveibeenpwned has certainly been doing it with passwords for quite a while. In any case, it's a bit of a stretch to call it a "twist" like they've had some magic new idea.
The k-Anonymity solution is checking whether a hash of client's choosing exists in a big dictionary of hashes on the server and involves returning a portion of the big dictionary to the client. That's not so bad because these big credential lists are semi-public anyway, but it's not ideal. Further the server has some idea of which data was queried because it may be in the returned data, and the server (for some scenarios) knows the corresponding plaintexts for hashes in it's dictionary. For example if the client queried a series of hashes of email+password pairs the server could easily deduce the email address that was common between the returned subsets. I suppose that's the reason they're implemented to check only password hashes (HIBP) or only email addresses (Firefox), rather than full credential combinations? (Hopefully I have all this right).
MS's solution appears to be checking full credential combinations and essentially involves revealing the existence or not of the credentials in the dictionary to the client, and nothing to the server. The server receives credentials encrypted by a session key only the client knows, so it cannot even know whether two queries are identical or not. The client meanwhile only learns whether a credential is in the dictionary if it knows it's full hash ahead of time. It can't download a bunch of hashes en masse and then attempt to crack them together efficiently.
That's the idea anyway. There are lots of details they've had to add to the protocol to make it computationally tractable and potentially there's some weakness in it. I guess we'll see.
Amazing the disablement of commentards who can't even lookup the technical terms.
Homomorphic encryption, as in "allowing one to perform calculations on encrypted data without decrypting it first."
Similarly I can see you're intellectually lazy without actually having to look at you.
Robert Carnegie wrote: "How can it work?"
A toy example was given in comments to <https://forums.theregister.com/forum/all/2016/02/09/researchers_break_homomorphic_encryption/>
"> You can't do data analysis on data that you don't have.
As an illustration: Let us suppose that the analysis consists of multiplying two numbers together and checking whether they are greater than another pair of numbers multiplied. This analysis is to be provided without revealing what the numbers are.
The data owner can provide the numbers as logarithms of some 'secret' base; not knowing the 'secret' the analyser cannot discover the numbers. But, they do know how to multiply numbers expressed as logarithms (you add them) and they do know logarithms maintain order. Therefore they can complete the analysis without knowing the actual numbers.
Obviously in a truly secure system the techniques and the maths are more complex."
HTH
I was once doing a review of security at a government agency which had offices all over the country. In the local office there was, according to their security officer, a minimum password length set of 10 characters. The SO wanted to come with me as I interviewed staff, and I said ok, but please don't say anything, and the staff might just say things that surprise you if they forget you are there.
Well, two ladies were interviewed together, and I asked about the length of their passwords. One was adamant the hers was only 8 characters, and she tested it (without revealing it), and it was only 8 characters.
The SO was quite surprised and, fortunately, impressed. There followed a review of the IT security implementation (by him not me).
"No one wants a personalized ad based on browsing history ruining all the fun," said Microsoft, using the example of a surprise gift's recipient perhaps seeing an ad over the user's shoulder.
A prize to whoever thought up *that* example so that they didn't have to admit the *actual* motivating example.
I don't but I was somewhat surprised that after buying a new CD player and amp from one company they sent me sales brochures for their CD players and amplifiers for over 2 years.
I can only assume they were hoping that the products I had bought had so impressed my friend(s) that there was the possibility of a follow-on sale.