A tiny webapp to help answer that question.
A friend had an SSL scare on public WiFi while in a coffee shop today. Her browser was warning her that every SSL certificate was invalid (except for
*.google.com). Eventually it stopped, and she overheard others in the coffee shop commenting that their tablet was finally able to connect (it was previously refusing).
I'm not sure, but this could be a man in the middle attack on the WiFi, in which the attacker (somehow) had a valid Google certificate and provided DNS records to point at their own machine.
In this scenario the browser is perfectly content to allow you to connect to this spoofed service. If you are not extremely familiar with SSL certificate authorities, a good way to assert a cert is not a forgery is to compare it to a known-good copy of the certificate. If the signatures match, then you are good to go.
But where can you get a known-good copy?
To answer this question, I quickly make the SSL Cert Fetcher (the source of which is available on GitHub).
Take a look at the certificates for Twitter, Google, and Facebook and see if they match what you are getting. (I'll sit here with my fingers crossed for a while.)
A quick peek at the Adobe password breach.
Recently, someone broke into Adobe's network, stealing source code and part of their password database. It later turned out to affect at least 38 million people.
I always try to investigate to see if I am personally impacted by these leaks. Usually, that means submitting a carefully hashed password to some online service built to inform you if you were part of the leak. This time, however, the entire file was readily, and easily availible (by which I mean my Twitter feed included a link to it, several times).
So... why not take a peek?
$ grep mikeboers cred
While not surprising, I am still dissapointed to be included.
Digging just a little bit deeper, there are some very troubling things in this file.
Read more... (2 minutes remaining to read.)
I recently watched a TED talk by Ralph Langner, lead of one of the teams attempting to reverse engineer the virus to determine its purpose. My original reaction on Twitter was:
The most terrifying part about this attack is that while it was highly targeted, all of the exploits and actions it took are remarkably generic and can easily be retargeted to many other types of systems. There are many targets, and they are very vulnerable. The community of engineers and developers working with these sorts of control systems have, up to this point, not felt the need for a level of security paranoia that many software systems presently require.
There is some good discussion in the comments on Reddit:
It turns out the issues I was having compiling OATH-Toolkit was due to a slight change to the build process introduced in version 1.8.1. It is something to do with autoreconf, but I wasn't able to properly diagnose the problem. Ergo my workaround was to simply build only the parts that I needed:
tar -xzf oath-toolkit-1.10.2.tar.gz
make -C liboath
make -C pam_oath
make -C liboath install
make -C pam_oath install
And now I have time-based one-time-passwords on my Mac as well. The next thing to do is figure out how to get it to check against hashed passwords so I can get back to using a single prompt...
I have been meaning to beef up the security on my various servers for a while. Everything was configured in a way that was relatively closed, but ultimately I decided that convenience outweighed absolute security. To that end, my passwords are not as good as they could be (ie. I can remember them easily and type them quickly (although they were designed to be...)), SSH continues to serve from the default port, and one could SSH to root just with its (enormous) password.
Walking home from the train yesterday I decided to finally fix this. My original idea was to setup a pluggable authentication module (PAM) for Steve Gibson's "Perfect Paper Passwords", but I soon discovered the (slightly more official) Initiative for Open Authentication (OATH). OATH provides specifications for two types of one time passwords (OTPs): event based (HOTP) or time based (TOTP).
Event based OTPs are generated from a counter that increments every time you ask for a password. The servers keep track of the current counter so they will never accept previous passwords again (eg. if someone watches over your shoulder or there is a key logger). Time based OTPs do much the same, except they are based off of the current time and so are only valid for the current 30 second block.
These sorts of two-factor authentication schemes often rely upon proprietary hardware and expensive service plans, but the openness of OATH allows for free apps for iOS, Android, and many more. Another open source project, OATH Toolkit, provides the server side code including a PAM.
Read more... (6 minutes remaining to read.)
There are no more posts tagged "security".