On Saturday I was saved by a second factor of authentication.
I was playing the new SimCity game on my home computer in the basement, when my gaming session (surprisingly, it was playable that day) was abruptly terminated because my account had been logged on in a different location.
Seeing as how I only had one computer with the Origin software installed, I was surprised by this, so I restarted the game. It told me that I was logged on somewhere else, and if I logged on it would log me off the other location. “Sure, sure, whatever.”
A minute or two later, the same thing happens. Then I realize what’s going on.
I’ll admit, my Origin.com password was horrible. It was four characters long. That said, I was surprised that someone had bothered to capture it. The only game I have is the new SimCity, and it’s problematic as I alluded to in the earlier link.
So I again logged on, forced out the other user, and then went straight to the “change password” link. Here’s where things get fun. Origin’s password reset system requires you to not only have the current password, but also have the answer to your “secret question”. The problem is, my secret question was currently in cyrillic. (Looks like this isn’t uncommon.) So, I didn’t know the answer.
Luckily, the “I forgot my password so please send it to my email” link does not require the secret question to get involved. So I clicked that, got the email, and used the link in the email to reset my password. After that, I spent 30 minutes waiting for an EA technician on chat support to help me change the “secret question”. So now I feel like my account is safe.
Then I walked upstairs and was greeted by 6 voicemail messages on my cellphone. All of them were just strings of digits. This is one of the messages. It turns out, the attacker tried then to gain access to my email account by using the password I had used on Origin, and had kicked off some password reset attempts. Since I had configured my email to require a second factor of authentication (call to my cellphone) before allowing the password to be changed, my email account remained under my control – for now.
So the moral(s) of the story? Use a better password than I did, and make sure you set up second factors of authentication on all the accounts you can. As Smokey the Bear would say if he switched his focus to information security: “Only you can prevent account hijacking.”
Numberphile recently posted a video about the math behind RSA encryption. In the video below, a brief description of public key cryptography is given and then we are shown a simple example of the math used to perform encryption and decryption (math example @ 2:25).
In the video, James skips over the method for determining the private key, so I thought I would run through the key generation steps for his example.
- Choose two distinct prime numbers p and q.
These are the two primes that he mentioned, so
p = 2and
q = 5.
- Compute n = pq.
Simply multiply 2 and 5.
n = 10.
- Compute the totient of n, or
(5-1)is 1 times 4 which equals 4.
- Choose an integer e greater than 1 and less than the totient of n such that e and the totient are coprime.
There are only two integers between 1 and 4. Two divides 4, so the only choice left is 3. At this point, we have the two components of the public key,
n = 10and
e = 3.
- Find d where d times e equals 1 modulo the totient.
- 0 times 3 is 0 and the remainder of 0 divided by 4 is 0.
- 1 times 3 is 3 and the remainder of 3 divided by 4 is 3.
- 2 times 3 is 6 and the remainder of 6 divided by 4 is 2.
- 3 times 3 is 9 and the remainder of 9 divided by 4 is 1. Therefore,
d = 3.
In this case, the public exponent e and the private key d are both 3. That’s why the values were cubed in both encryption and decryption. The cubed values were divided by 10 which was the n we computed in step 2. The remainder of the division yielded the encrypted or decrypted message.
Yesterday, this story on Wired was making the rounds: How a Google Headhunter’s E-mail Unraveled a Massive Net Security Hole. Sure, the title is probably hyperbole, but it is an interesting story. At a high level, mathematician Zach Harris noticed that emails from Google – and from several other prominent domains including eBay, PayPal, Yahoo, Amazon, etc. – could be spoofed.
Anyone who has ever run telnet to port 25 and sent an email from firstname.lastname@example.org or email@example.com knows that email has always been pretty easy to spoof. Given the rise in unsolicited emails also known as spam, something had to be done. In 2006, a working group was founded to try and create a standard that would make email harder to spoof. It is called DomainKeys Identified Mail or DKIM. The way DKIM works is that the sending email server applies a digital signature to the mail message headers (completely transparent to the user). The public key which can be used to verify the signature appears in the sending email server’s DNS record.
Since it uses some fancy technology like a digital signature and relies on DNS – a core capability of the internet – email with a valid DKIM signature can generally be trusted that it is legitimately from the domain listed in the From field… Well, that is if you’re doing DKIM correctly.
Mr. Harris found that the DKIM signatures for a number of popular domains used such weak cryptography that it was very easily cracked. While the DKIM standard calls for 1024 bit keys, he found popular domains with 768 bit, 512 bit, and even 384 bit keys. As he points out in the article, he was able to crack the 384 bit keys on his laptop, and for $75 he cracked some 512 bit keys by outsourcing the computing power to Amazon Web Services.
The best quote in the entire article, and the reason I bring this story to your attention is the following:
“People who use cryptographic tools need to realize that local configurations need to be maintained just like software updates need to be maintained,” he says. “In 1998 it was an academic breakthrough of great concerted effort to crack a 512 bit key. Today little old me can do it by myself in 72 hours on AWS. The field of cryptography keeps developing and breaking new ground just like everything else, and you can’t just install a private key, or select a hash algorithm, and expect it to be good forever.”
Wise words, indeed. If connected to any network, you must consider your operating system, your software, and your cryptographic algorithms and keys all as perishable items. They need to be examined for mold and rot periodically, and replaced when necessary. You can no longer afford to “set and forget” anything and consider it dependable.
It’s a little embarrassing to admit, but it seems that the mistakes of one person globally syndicated columnist have led to a rapid increase in the acceptance and use of two-factor authentication technologies for authentication. Within the last week, I have set up both my Dropbox account and this very blog with two-factor authentication.
Mat Honan’s sordid tale did a lot to raise awareness of how passwords are imperfect as an authentication mechanism, as have the many password breaches that have occurred over the years. Most interesting, though, is how Google created and freely released Google Authenticator as an open source application and how quickly organizations have begun to embrace it. While I’ve traditionally been a PKI guy (I know, that’s SO 2003), when the time came for us to secure our VPN with a second factor we went with Google Authenticator rather than a PKI token. Why? Cost. Hard to argue with free.
So now, I have Google Authenticator token set up with: my personal Google account, my corporate Google Apps account, my corporate VPN, my blog, and my Dropbox. What do you think the next systems to add Google Authenticator support will be? Let us know in the comments.
To improve performance, particularly for mobile users, many websites have started caching app logic on client devices via HTML5 local storage. Unfortunately, this can make common injection vulnerabilities even more dangerous, as malicious code can invisibly persist in the cache. Real-world examples of this problem have now been discovered in third-party “widgets” embedded across many websites, creating security risks for the companies using such services – even if their sites are otherwise protected against attacks. Striking a balance between security and performance can be difficult, but certain precautions may help prevent an attacker from exploiting local storage caches.
Throughout the history of web development, people have found ways to use and abuse various technologies beyond their intended purposes. Before CSS gained widespread support, many developers created complex layouts with HTML tables. Now that browsers provide far more presentation-layer tools, one can recreate complex images using only CSS. Such tricks can at times be very helpful in overcoming the limits of a browser-based environment, but they can also inadvertently create security issues.