Security

SSL: Really broken this time

Cryptographers have exploited a known weakness in the MD5 algorithm, allowing them to create forged digital certificates. Doing so potentially trashes any security provided by the HTTPS protocol.

A part of SSL is broken, and that's serious. Not being able to trust secure Web sites totally affects all of us, and I'd certainly be remiss if I didn't make sure everyone understood what's happening.

To begin with, it's important to understand SSL certificates. If there's any confusion, please refer to the following two articles that I wrote about SSL certificates: "SSL/TLS Certificates: What You Need to Know" and "SSL/TLS Certificates: Perspectives Helps Authentication."

In the articles, I initially explain that untrusted certificates are insecure and ripe for phishing exploits. Simple because most of us just OK the untrusted certificate regardless of the warnings; we're impatient and just want the Web page to be served up. That's still a problem, but things just got a whole lot worse, and I'll explain why in this article. A little background information first though.

Creating SSL certificates

I also mentioned in the articles that SSL certificates become trusted because they are provided by Certificate Authorities (CA) such as Verisign and Network Solutions. The logic behind all of this is quite simple. The CA authenticates the Web-site host so users can trust the secure Web sites provided by that particular hosting organization. People interested in cryptography call this a chain of trust The research team that discovered how to break SSL has an excellent definition of SSL certificates in their article "MD5 Considered Harmful Today":

"A certificate is a document that contains both an identity and a public key, binding them together by a digital signature. This digital signature is created by an organization called a Certification Authority. This organization guarantees that upon creating the digital signature it has checked the identity of the public key owner (e.g. Web-site host) and it has checked that this public key owner is in possession of the corresponding private key.

Anybody in possession of the CA's public key can verify the CA's signature on the certificate. In this way the CA guarantees that the public key in the certificate belongs to the individual whose identity is in the same certificate."

To avoid confusion, I wanted to clarify that SSL certificates are a subset of digital signatures. With that in mind, I'd like to continue using the term digital signature since the researchers do as well.

Why are digital signatures used?

I thought it might be a good idea to review why digital signatures are important to SSL. Digital signatures are used to create the chain of trust I mentioned earlier. The way digital signatures accomplish this is through the use of public-key cryptography. Public-key cryptography can be a whole discussion in itself, so please refer to the RSA article "What Is Public-Key Cryptography" for a helpful definition.

With public-key cryptography, we start to see how information from a CA if signed with its private key (something that only it has) is one method for the CA to prove its identity. This verification process consists of two parts -- signature generation and signature confirmation:

  • Digital signature generation is the result of hashing the message (consisting of the CA's identity and the public key of the Web-site host) with the CA's private key.
  • Digital signature confirmation is accomplished by the Web browser during the HTTPS handshake between it and the secure Web site.

If everything is working properly, the Web browser will use the CA's public key to decrypt the digital signature and verify the CA's identity against the list of CA signature files (almost 300 to date) encoded in the Web-browser application.

Once the identity is confirmed the Web browser can initiate a SSL tunnel with the Web site using the public key sent in the CA's digital signature. The following diagram depicts the normal HTTPS handshake (courtesy of the research team):

normal-cert.png

Trusted certificates are no longer a sure thing.

All is not well with the supposedly secure connections between Web browsers and Web sites using HTTPS. As is typical with IT security and especially cryptography, protocols and concepts that have been around for a long time slowly start to cause trouble. In this case the MD5 algorithm is one of those old timers.

The following is a brief outline of the attack taken from the article "MD5 Considered Harmful Today," written by the team of cryptographers who discovered the potential exploit. The team consisted of Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, and Benne de Weger:

"Our attack scenario basically is as follows. We request a legitimate website certificate from a commercial Certification Authority trusted by all common browsers. Since the request is legitimate, the CA signs our certificate and returns it to us.

We have picked a CA that uses the MD5 hash function to generate the signature of the certificate, which is important because our certificate request has been crafted to result in an MD5 collision with a second certificate. This second certificate is not a website certificate, but an intermediary CA certificate that can be used to sign arbitrary other website certificates we want to issue.

Since the MD5 hashes of both the legitimate and the rogue certificates are the same, the digital signature obtained from the commercial CA can simply be copied into our rogue CA certificate and it will remain valid."

Collisions are bad

As with many cryptographic concepts, encryption-based security relies on the fact that huge amounts of time and/or money are required to come up with a solution or in this case a collision. The term is actually appropriate, since a collision occurs when two different hashed entities like digital signatures end up being identical.

Since the strength of a digital signature is entirely based on the premise that it's virtually impossible to have two identical digital signatures, collisions are a bad thing. Now guess what the researchers have been able to do. That's right; they were able to figure out how to generate collisions for known hashes.

More importantly their approach doesn't take that long and is definitely low budget. The research team used Arjen Lenstra's Playstation lab at EPFL, which consists of 200 PS3s as shown in the image below (courtesy of Lenstra and EPFL):

ps3cluster.png

I'd like to once again refer you to the article "MD5 Considered Harmful Today," as the researchers do a much better job explaining the details of how they were able to reliably locate MD5 collisions.

What's it all mean?

It means an attacker could mimic a secure Web site like Amazon.com, and there wouldn't be any indication that the displayed Web pages weren't from Amazon's Web server. The URL would have https in it, the lock would shut, and the user would be none the wiser. Needless to say that sounds scary; still this exploit by itself is almost useless.

So what's the problem? It becomes a huge concern when the MD5 collision exploit is used in concert with exploits that redirect traffic. Consider a blended attack that uses Kaminsky's bug and the MD5 collision exploit. The attack could consist of redirecting a user to a malicious Web site that is mimicking the user's bank portal.

Another attack vector could consist of two parts. First subvert a network by using the DNS Changer trojan. Ultimately service up fake DNS records, which happen to point a user's Web browser to malicious Web sites, and well, you know the rest. The following diagram (courtesy of the research team) outlines the steps required to carry out a redirection/MD5 collision attack:

redirected-cert.png

How to fix the problem?

That's a good question. There's woefully little that we as users can do to prevent these types of exploits. Just understanding what's happening is our best defense at this time. So I wanted to make sure everyone knew where these digital signature files were located in the various Web browsers. Pay particular attention to the signature algorithm. That's the private key algorithm CAs use to generate the digital signature file. The steps listed below show where the files are located in the Internet Explorer and FireFox browsers:

Internet Explorer

1. Start Internet Explorer.

2. Go to Tools and click on Internet Options.

3. Go to the Content tab and click the Certificates button.

4. Select the Trusted Root Certification Authorities tab.

ie1.JPG

5. Double-click a certificate of interest.

6. Select the Details tab and check the Signature algorithm.

ie2.JPG

FireFox

1. Start FireFox.

2. Go to Tools and click on Options.

3. Go to Advanced and click on the Encryption tab.

4. Click on View Certificates and select the Authorities tab.

ff1.JPG

5. Highlight a certificate of interest and click View.

6. Choose the Details tab and check the Certificate Signature Algorithm.

ff2.JPG

If you notice, in the above examples I kept highlighting the Equifax certificate. This particular certificate was the one exploited by the researchers. As you can see, Equifax is using MD5 as the signature algorithm.

This is where users have an option. If the SSL certificate is signed by a CA that's still using MD5, the collision exploit is entirely possible. If the CA uses SHA-1 for its signature algorithm, the SSL certificates are not affected by this exploit. At least as of yet, there is some concern as SHA-1 has a similar collision problem.

Final thoughts

Whew, yet another major Internet issue that leaves users vulnerable to some potentially heavy-duty exploits. As with the DNS vulnerability, users are pretty much at the mercy of others as to when and how this gets fixed. Hopefully Certificate Authorities and Web hosts will stop using MD5 and even SHA-1, switching to SHA-2, which raises the bar and is recommended by the research team that found this flaw in SSL.

One thing I see in our favor is that on-line retailers will certainly drive these changes, because they certainly don't want to lose our business.

Need help keeping systems connected and running at high efficiency? Delivered Monday and Wednesday, TechRepublic's Network Administrator newsletter has the tips and tricks you need to better configure, support, and optimize your network. Automatically sign up today!

About

Information is my field...Writing is my passion...Coupling the two is my mission.

131 comments
Cimmaron
Cimmaron

Looks like the common CA's should now take the added responsibility of not signing and issuing new certificates that collide with the CA signatures normally in the browsers. That seems like a small overhead.

oddacorn
oddacorn

I'll admit that a lot of the intricate details of this are over my head, but in the last diagram that details how the exploit could be used, I notice that in step 3 the rogue website has to issue both a web site certificate and a bogus CA certificate. Wouldn't it be possible to short circuit this problem by not allowing browsers to download CA certificates? Presumably the makers of the browsers have some way of verifying that all of the CA certificates they bundle with their apps are actually legit, and we could go to them for updates. Just a thought. Todd Corson Houston, TX

harry.graham-brown
harry.graham-brown

Is a certificate with a MD2 hash bad too? I assume that MD2 is a predecessor to MD5 and therefore it is bad. E.g. OU = Class 3 Public Primary Certification Authority O = VeriSign, Inc. C = US uses md2RSA

ahmad_mohamads
ahmad_mohamads

collision free hash or Redesign MD5 Algo.: I have seen and read a well documentation on the subject of collision of hash functions that the key size must be 2048 bits or even more to obtain a collision free hash, on the ELdos.com web site for SSL products for Developers & they refer their information to a research done on collisions providing a url link too. Any one can visit www.eldos.com and search for sslbox component then search documentations provided on describing hash function until you find the collision subject on hashes. So if the fault is in that part , we should increase the size of the keys to more than 2048 bits. If it is in the MD5 Algorithm it self It must be redesigned to prevent its current flaw. if it is due to MITMs attack on the Public key interception that is possible and even finger prints can not prevent MITM from creating a fingerprint for his key and send it to both client and server to cheat them . There is one more solution remains , and that is a software base solution to exchange a symmetric Key between the entities communicating without sending the key on the fly ,So.. that way BY BY to MITM fore ever. Then start the rest of Communications securely. mohamad ahmad

a.southern
a.southern

In that photo of the PS3s, I count 88 on the side we can see, and we can only see 9 on the first column on the side we can't see. Even if we assume the two sides to be symmetrical, that'd only be 176 PS3s. Where are the other 24? Are we to assume they are "on loan" to the staff, and the staff are having a big networked game of "Grand Theft Auto" or something? -AS

sbrinker
sbrinker

Isn't it possible to use some kind of reverse DNS lookup to guard against a contaminated DNS cache?

Michael Kassner
Michael Kassner

I'm not really following what you mean. Sorry, I'm slow and old some of the time. If I do understand, the CAs don't issue new certs, it that the original ones can be mimicked by nasty types.

Michael Kassner
Michael Kassner

The attacker has the ability to mimic a CA signing certificate. By doing that the Web browser then automatically trusts the Web host certificate and public key.

Michael Kassner
Michael Kassner

Hello Harry, Sorry it took so long to answer. You are correct in your assumption. In 2004, MD2 was shown to be vulnerable to a pre-image attack. I also seem to remember that researchers found evidence of collisions as early as 1997.

Michael Kassner
Michael Kassner

Exchange the symmetric key? That's always been the problem. If you could solve that, I'm sure many people would be really happy.

adelacuesta
adelacuesta

That's a good point. DNS security is teh responsibility of the ISP. I think the only redirection will be from the DNS side aside from users must be very aware against phishing. Chaseonline has extra step in their transaction by alerting/asking the user everytime someone access the banking data.

Michael Kassner
Michael Kassner

The DNS servers are the problem, in most cases. The client is being redirected to malicious DNS servers. I suspect that those servers would respond with the correct host names for a reverse DNS query. It's an interesting thought. I'd like to ask some friends who are much more in the know about this and get back to you.

kevrain
kevrain

If images are considered multi-factor authentication, then we are still thinking like a rookie. Images and phrases are still "what you know" which is the same factor for username and password. By adding a one-time password generator, you add "what you have" to "what you know" for a true two-factor authentication (2FA). B of A now offers a card token called SafePass that generates a 6-digit One-Time Password (OTP) that authenticates the user's card token. Thus, even if the site is compromised, the user will possess the only device that can authenticate their identity to the bank's legitimate website. The 2FA method can also be used on a per transaction basis if desired. So you still have the problem of a MitM attack that passes the OTP through to gain account access but it would only be good for that login. The attackers would not be able to login to the account at a later time using the same OTP. Another challenge is to validate the legitimate bank website back to the user. This wouldn't be necessary if a transaction required 2FA. It would be even more difficult if the OTP was validated out-of-band via a text message or outbound call to your cell phone that prompts for an OTP response before executing a large transfer of money or payment transaction. OTPs are either event-based or time-based, the latter being stronger since the OTP number is only good for a few seconds while the event-based OTP is good until it is used. Time-based OTPs make it even more difficult for attackers since it limits the amount of time they have to conduct a MitM attack. We need to move on from single factor passwords to make it harder for attackers to gain access to our accounts and also our transactions. I'd like to see out-of-band second factor authentication requests for transactions over a user-defined dollar limit. That way, if a fraudulent payment or money transfer is being conducted, I'll get a request to authenticate it and be made aware of the fraud and deny the request. A denial can trigger a red flag to the bank to investigate the source of the transaction request. Just some thoughts from a free agent looking for work in the identity security industry.

uranthos
uranthos

Just look at the 'computer' terminals.. every last one of them is a PS3. don't know how any work was achieved using a ps controller... be to busy playing tekken l)

a.southern
a.southern

I'm guessing they don't need central heating in the winter......

ctaylor
ctaylor

USAA's website (usaa.com) requires that you select one of perhaps a thousand icons to associate with your login account. If you log into the account and don't see the picture of a cat, strawberry, building, boat etc that you previouly associated with your profile, then you should consider the website compromised, and report the incident immediately. This feature has been in place for some time. This approach doesn't work for everybody, but does allow the client one more means to feel that they truly have logged into the correct secure website and avoided malicious certificates and DNS redirection.

techrepublic
techrepublic

But it would only work if the DNS wasn't poisoned/hijacked as mentioned. The entity (likely would have to be the browser) could have its own DNS settings separate from the operating system. For example using a public one like 4.2.2.2. That way in order to successfully beat the lookup you'd have to compromise both DNSs -- OR -- capture the port 53 traffic itself and feed the clients false replies, which would be the much easier way. There would be no defense against that. It's not something you could do sitting in your basement hacking away, but somebody placed inside an ISP could do it. We're potentially talking about lots and lots of dollars behind the collected information here so don't think that can't happen. One of the perimeter security devices I deploy professionally (and do certification training for) has a feature you can turn on that actually does a reverse lookup on the name in the certificate to see if it agrees with the IP that the traffic is actually coming from. Works great for major sites. But guess what -- and here's the problem with that method -- self signed certificates fail that check. Which brings us back to one of your original points, about how everybody just allows those certificates. Well, with this device in place and that feature turned on, you can't, the firewall just plain blocks them. Which from a security point of view, might be a really great thing. From a user point of view, not so much. But that's always the balancing act, isn't it?

Michael Kassner
Michael Kassner

I understand your issue with multi-factor authentication all too well. I guess I was negligent in pointing out that we were discussing something a little different than the actual log in procedure that you outlined very nicely. The image would be a verification that the Web site isn't a mimicked one and that's all. It's simple to implement and wouldn't be cost prohibitive. That's what we were referring to as having more than one factor to identify the Web site. Sorry for the confusion Your mention of single-use tokens and out-of band messages would also do the same thing and have the advantage of multi-factor OTP authentication.

Michael Kassner
Michael Kassner

He also mentioned that it would be one heck of a real-time LAN party.

JCitizen
JCitizen

I wish you were the one that wrote the intro articles on Vista here at TR two years ago, I would have picked up a lot of great facts. Although I am disappointed at having to re-install the operating system for the third time, I must admit things are working really well now,(third time a charm, I guess)! Windows Media Center is running smoother than ever, I have yet to catch any maleware that AdAware can't easily dispatch; and for now Norton hasn't left it's post as system watchdog. (Just yet anyway) It could have been that all the latest Windows updates had to be applied all at once, before anything else was installed. I will probably never know why I've had so many problems up to now.

Michael Kassner
Michael Kassner

Still should remember to define questionable terms. Otherwise my old debate coach (a real hero of mine) would be upset.

Michael Kassner
Michael Kassner

The 64-bit version contains a security feature called Address Space Layout Randomizer. This feature causes a random offset to be applied when system files are loaded. This means that unlike the 32-bit version of Vista, system files are rarely located in the same memory location twice in a row. This randomization foils many of the exploits that are commonly used against Windows today. Another security feature found only in the 64-bit version is something called Data Execution Prevention, which keeps executable code from running in certain areas of the system's memory. The 32-bit edition of Vista includes a less sophisticated version of this feature that is implemented through software, but the 64-bit version enforces Data Execution Prevention at the hardware level.

JCitizen
JCitizen

Veeerrryy interesting!(as that guy on Laugh - In used to say, HA!) I did find out Windows XP Professional 64 bit Edition was more secure as it was written in the NT 5 kernel, same as Server 2003. I was surprised at the security improvements over 32 bit XP. However I was not aware of the Vista advantage; I guess I shall do a Google and learn more of this!! Thanks again!!! =)

JCitizen
JCitizen

that we the public are ignorant; Ifeel the banking industry should by law explain everything accurately and by standards to the customers. My credit association tries but if there were standards like HIPAA, they would try harder, by law.

Michael Kassner
Michael Kassner

64 bit operating systems from MS are significantly more secure. As I understand, the advantages leveraged by TPM only really come into play if the OS is 64 bit enabled.

Michael Kassner
Michael Kassner

As with everything related to security, definitions are ultimately important. I apologize as I'm negligent in that I don't always clearly define the terms and that leads to confusion.

JCitizen
JCitizen

Now I can talk to my bank with some confidence about the subject. Seems they only have one factor going on there! Their multi-factor claim is pretty bloated by the standard you relate here. I'm not surprised at their ignorance, though. They look like deer caught in the headlights when I ask them what formula they use for calculating interest on various loans. ROTFLOL! :^0

JCitizen
JCitizen

however the developer of Snoopfree never recovered his time in developing the software for XP. So I doubt he will repeat his performance. I think he would have received a lot more donations if he had placed a secure paypal link on his site. It's kind of tragic. I've never heard of any malware defeating his simple program, which I believe is a rootkit in nature.

Michael Kassner
Michael Kassner

I can't help there, I'm still on XP and 32 bit at that. I'll ask around though, as it's interesting. Are the TPVs low-balling Vista and waiting for 7?

Michael Kassner
Michael Kassner

Multi-factor authentication is very clear that each factor has to be unlike the others. I'm sure you have read about these as being the factors: ? Something the user knows (e.g., password, PIN); ? Something the user has (e.g., ATM card, smart card); and ? Something the user is (e.g., biometric characteristic, such as a fingerprint). Requiring a response from all three groups would be a strong authentication process. If you want this white paper by the banking industry ( 2005, but still pertinent) is a good read: http://www.ffiec.gov/pdf/authentication_guidance.pdf

Michael Kassner
Michael Kassner

It appears that if the verification factor is more than a one-time event, the process is flawed. Just about any application or process that does not introduce randomness can be figured out. This discussion has really driven that point home. Very cool.

JCitizen
JCitizen

Yes they do, and yes I am; however I was not aware their firewall was capable of reading video hooks. In fact my Snoopfree Privacy Shield(XP) trips many times when Comodo doesn't. I suspect it is because Comodo doesn't actually look at the input/output process, but instead monitors keyboard file hook processes. Besides, I'm stuck with NIS 2009 and I'm sure Symantec and Comodo don't get along. Any corrections are very welcome.

JCitizen
JCitizen

If the cracker has malware on your computer and hooking your video in the session he could record the image and make life easier for him in the process. A keyboard hook is nice but not necessary as almost everything you type in Windows gets recorded to the hard disk. It only takes about 5 seconds to gather pertinent information from these files. I could really use a good video/keyboard Input/Output firewall that works with Vista x64 about now!

JCitizen
JCitizen

to all be passwords. Athough the questions are a small set, the answers are not, they would be completely individual. I was sure they were bragging that it was five factors, but whoever wrote the letter may not know what they were talking about. In the first page you have to know the account number; and of course the usual security code to prevent robot attacks. Then the second page ask one of a subset of general questions, but the answer is completely individual. The generalized questins are randomized. In the third page you must enter you PIN and this is the standard image page also, this is where an individual image would be better, but this one looks like one of those electronic watermarks; I don't know how easy those are to mimic. It is definitely multi-factor at any rate; and when I tested the SSL I noticed the RSA key lenght is only 1024 bits long; 2048 is better. Also the certificate has no SGC; dangerous no?

Michael Kassner
Michael Kassner

If I understand your comments correctly, you are right in assuming that approach does little to help. The attacker gets everything credentials and image. That's why the image would need to be shown and verified before the user completed the login.

MarkGyver
MarkGyver

The way I see it, if there's anything that only the user and the institution should know, and the institution only gives the info after being given the user's credentials; wouldn't it be trivial for the evil site, after getting the user's credentials, to proxy those credentials to the institution and proxy back the return info, recording everything in the process? For example: 1. User goes to evil site that's posing as the institution's site, which uses picture verification 2. User enters their account number 3. Evil site sends account number to institution 4. Institution sends verification picture to evil site 5. Evil site shows user verification picture 6. User sees picture, is reassured that it's the right site, and enters their password This adds a few extra steps to the process, but I doubt the user would notice the extra tenth of a second taken. Conclusion: Either I'm missing something major, or the picture verification only slows things down for the site spoofer and slightly complicates their scripting.

Michael Kassner
Michael Kassner

Are you using 64 bit? Do I remember you mentioning Comodo? As they have one.

Michael Kassner
Michael Kassner

Jaqui, I hope things work out OK for you. I know it's only small consolation, but you look really good in shades.

Michael Kassner
Michael Kassner

J, can you explain the process? If they ask 5 questions that's not really 5 different factors. All the questions would be considered one factor that represents "what you know" . It adds complexity, but it's not multi-factor. For example, passwords and questions together are multiple factors. Another point is that questions are weak in that most people use the correct answer, when initially setting up the account. As you know that's not the way to do it as they can easily be guessed. Remember the Hilton and Palin issues? I always use wrong answers when I have to set up accounts using questions. That's harder though as I have to remember the wrong answer then.

Jaqui
Jaqui

It may be from my own stupidity when younger being likely to actually make accessibility a requirement for myself that causes me to think of it. :D I'm already noticing the effects of it, I cannot see in bright light, it overloads my eyes completely. [ yes, sunny summer days I am effectively blind, really dark sunglasses gives me shapes only. but I can see through those in the middle of the night just fine. ]

JCitizen
JCitizen

This is what bothers me about Vista, as I have not found a good I/O firewall yet.

JCitizen
JCitizen

before the last authentication, however the image is not secret, I suspect so your idea is better. To let the user pick an individual image. However they do use five factor authentication, and this would be a difficult hurdle to pass as the questions are all individualized.

Michael Kassner
Michael Kassner

You always keep me centered. I really appreciate that. I need to investigate special needs and IT. I have a friend that has been blind from birth. He is an amateur radio operator and is so amazing. He climbs his tower to install or repair his antennas. I will definitely ask the teacher.

Jaqui
Jaqui

someone who is visually impaired can't see the picture. it just kind of seems really obvious to me. :D there would have to be some other mechanism for accessibility issues like that.

paulc245
paulc245

I find this discussion fascinating. Good article Micheal as always. My institution login asks for the account #. This is what is associated with the picture & phrase. If the picture and phrase are right then you enter the password, if not your at the wrong place Don't enter password and contact the institution. Small pain but good idea

Michael Kassner
Michael Kassner

That would help a great deal. Good for BoA. How is that set up?

Michael Kassner
Michael Kassner

I've read about that and I believe some financial institutions are using this approach. Anything to increase the number of factors is a good thing. Still, I also have read (cant' remember where) that there are some issues with this approach. Have you heard anything about that?

Michael Kassner
Michael Kassner

Excellent point. You right away realize that something is wrong.

wdewey@cityofsalem.net
wdewey@cityofsalem.net

I can't seem to find the articles I have seen on this before, but the basic premise is that the user selects a category or categories. Then when logging in there are X number of pictures displayed. The user simply selects the one that has something from the category in the picture. Pictures are put in different locations each time and different pictures are used each time. The thought behind this is that even if someone captures the selection they may not be able to figure out why that picture was selected. Used in conjunction with or in place of a password it would make logging in more secure and could make the user wary if their category didn't show up in the group of pictures. This paper looked like what I remember image based authentication to look like. http://www.netaro.info/~zetaka/publications/papers/awasee-UBICOMP2005.pdf Bill

ctaylor
ctaylor

You are right, a hostile site would still have captured your login credentials, but you would know about it. The idea of distributing responsibility to monitor for compromises accross the entire community of users is intended to allow for early detection and minimize the actual number of overall breaches. Should a user have their informatino breached, they could take immediate steps to mitigate the damages. This is huge improvement over the way things are normally done.

Michael Kassner
Michael Kassner

That's an interesting idea. I see it helping by allowing you to have another factor indicate that you are at the correct Web site. My concern is that it sounds like the image shows up after you log in. Does it work that way? If the site is malicious it still would have your log in credentials, even though you immediately realized the Web site was a fake one.

Michael Kassner
Michael Kassner

I'd be interested in hearing about the device you are referring to. Also have you used or thought about using Perspectives? I mentioned it in the article. It does help with the self-signed certs. It's somewhat cumbersome, unless you are using Firefox: http://www.cs.cmu.edu/~perspectives/index.html Also, I appreciate your first comment, except that the attack vector that you felt would redirect and send back false query responses is what Kaminsky's bug is all about. It's all really quite amazing and I for one am glad to see this kind of comment activity. This is something that should be understood by anyone that uses the Internet, so as to reduce the risk envelope.

Editor's Picks