Bruce Snyder's complete blog can be found at: http://bruceblog.org/

Items:   6 to 10 of 220   « Previous  | Next »

Thursday, May 9, 2013

It seems to me that authentication in general needs to change. The requirement to remember a password for every online service you use has proven to be a daunting task not only for users but also for businesses that must store the credentials to authenticate those users. Considering the dramatic increase in data security breaches in recent years, it's no wonder that the competition amongst password management software continues to increase.

Personally, I use a password manager that supports all the devices I use (MacOS X, iOS and Android) and has the ability to sync across them. Not only does a password manager store your username/password pairs in a secure file, but it also has the ability to generate passwords with a high entropy to guard against a brute force attack. But even this is a game of chase. Just like in the world of anti-virus software, it's kind of a reactionary game. That is, only as new viruses are discovered can the signatures of those viruses be added to the anti-virus software. The same applies to passwords -- as the ability to crack stronger passwords only becomes easier, the requirements for passwords become more strict. At some point the whole idea of passwords will become a counterintuitive exercise. Many services also require the use of security questions for password recovery but this is also a losing game given that most of the security questions offered are largely the same across many unrelated services. It makes me wonder if eventually the use of a text based password is simply an invitation for a security breach (e.g., 'Oh this person is using a text-based password only, no problem we'll just crack it').

Beyond the cracking of passwords, consider how much companies spend to support usernames and passwords. Just the other day I was locked out of a system and had to actually call the help desk for assistance because there was no online password recovery offered. Now think about the fact that the help desk I contacted supports many thousands of users all over the world. In fact, my need for support with a password is such a common request that there is a category in the phone tree dedicated to password support. I hazard a guess that the investment to provide this support alone is probably fairly high.

To protect against simple password cracking we've seen the rise of multi-factor authentication (MFA) whereby a password plus some other out-of-band methods are used for authentication such as a text sent to your mobile device, a phone call to your phone number of choice, etc. Financial institutions typically provide this capability and even Amazon provides a MFA feature to secure an AWS environment. Many companies provide employees with a small two-factor authentication device -- I'm sure you've seen a SecureID token from RSA, a similar device from Symantec or smart cards from various companiesj, but even these have been breached and/or have been proven to be flawed. Furthermore, these solutions are aimed at the SMB and enterprise markets for distribution to employees, not at the general consumer market. And beyond that, I've even been locked out of a SecurID token before which required a phone call to a help desk!

Earlier this year, a new group named Fast IDentity Online Alliance (FIDO) launched to bring forth a new type of multi-factor authentication and new usage models. From the FIDO website's description of What Makes FIDO Different?:

The range of technologies supported by the FIDO protocol will include biometrics such as fingerprint scanners, voice and facial recognition, as well as existing authentication solutions such as Trusted Platform Modules (TPM), Near Field Communication (NFC), One Time Passwords (OTP) and many others.
To learn more about FIDO, check out the How FIDO Works page describing the protocol, here's an image about it:



The short story is that a three-way binding occurs between the user, the device and the vendor's back-end system and it requires all three need to be present to use the system. What is intriguing to me is that this protocol is aimed at end users/consumers -- people like you and me.

The first company to be considered FIDO certified is Nok Nok Labs in Palo Alto, CA. This company provides a commercial solution to implement the FIDO protocol and is currently testing it at about 15 companies. What's really needed is adoption of such a solution by popular online services and Nok Nok Labs is already testing it's solution with PayPal.

Not only would it be more comforting to know that my payments and my funds are secured by more than a username/password pair, but it would also be more convenient not to have to remember a password for every website I use. But until something like the FIDO protocol becomes ubiquitous, we must continue to live with what we've got today.


Tuesday, April 2, 2013

After upgrading Macports recently, I started seeing the following error in the terminal when the .bash_profile is loaded:
__git_ps1: command not found
Upon investigation, I discovered that the bash completion for git has been split into more than one file. Previously, all that was needed in the .bash_profile was to source the single file for git like so:

if [ -f /opt/local/etc/bash_completion ]; then
. /opt/local/etc/bash_completion
fi
Since the update to Macports, now I also need to source the second file like so:

if [ -f /opt/local/share/git-core/contrib/completion/git-prompt.sh ]; then
. /opt/local/share/git-core/contrib/completion/git-prompt.sh
fi
After closing/creating the terminal tab, the error is gone.

Tuesday, April 2, 2013

If you're not aware of the ssh-copy-id command to copy your SSH keys to a remote server, then you should really check it out. It seems to be prevalent on Linux but it's not available in the BSD world (which means it's not part of Mac OS X).

Just last week I encountered some folks who were not aware of this handy little utility and it's definitely not the first time. So I thought I'd just mention it here in the hope that others might like the info as well. The ssh-copy-id utility is a shell script that, quite simply, copies your SSH keys to a remote server, sets up the permissions correctly and appends the keys to the remote-host’s .ssh/authorized_key file. For those folks like me on Mac OS X who want this script, here's a port of the script from Linux.

Here's a quick example of using ssh-copy-id from Linux:


bsnyder@ubux:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub 172.16.82.150
The authenticity of host '172.16.82.150 (172.16.82.150)' can't be established.
ECDSA key fingerprint is 83:df:ca:af:61:ab:59:cc:a5:08:28:f3:ac:72:87:18.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.82.150' (ECDSA) to the list of known hosts.
bsnyder@172.16.82.150's password:
Now try logging into the machine, with "ssh '172.16.82.150'", and check in:

~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

bsnyder@ubux:~$ ssh 172.16.82.150
Welcome to Ubuntu 12.10 (GNU/Linux 3.5.0-17-generic x86_64)

* Documentation: https://help.ubuntu.com/

bsnyder@ubuntu:~$
Notice that first I used ssh-copy-id and then I immediately logged into the machine using the key (i.e., without a passphrase).

This task is certainly something that's relatively easy to do manually, but why expend the effort on a manual solution when there's something pre-built for the exactly problem?


Monday, March 18, 2013



I love this photo.

Tuesday, March 12, 2013

Again, lately I've been working on a project that requires the use of SSL and therefore certificates. This is just a note for my own posterity more than anything, but if you ever need to grab a SSL certificate from a host so that you can import it into your keystore, here's how to do so using the OpenSSL s_client:

$ openssl s_client -connect <host>:<port> > foo.cert
Just make sure to substitute the <host> with the DNS name of the host and the <port> with the actual port number. Once you have the foo.cert file, you will need to manually clean up the foo.cert file a little bit, but it works. Here's a quick example:

$ openssl s_client -connect yahoo.com:443 > yahoo.cert
depth=0 /serialNumber=2g8aO5wI1bKJ2ZD588UsLvDe3gTbg8DU/C=US/ST=California/L=Sunnyvale/O=Yahoo Inc./CN=www.yahoo.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /serialNumber=2g8aO5wI1bKJ2ZD588UsLvDe3gTbg8DU/C=US/ST=California/L=Sunnyvale/O=Yahoo Inc./CN=www.yahoo.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /serialNumber=2g8aO5wI1bKJ2ZD588UsLvDe3gTbg8DU/C=US/ST=California/L=Sunnyvale/O=Yahoo Inc./CN=www.yahoo.com
verify error:num=21:unable to verify the first certificate
verify return:1
^C
$
$
$
$
$ cat ./yahoo.cert
CONNECTED(00000003)
---
Certificate chain
0 s:/serialNumber=2g8aO5wI1bKJ2ZD588UsLvDe3gTbg8DU/C=US/ST=California/L=Sunnyvale/O=Yahoo Inc./CN=www.yahoo.com
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIE6jCCBFOgAwIBAgIDEIGKMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTAwNDAxMjMwMDE0WhcNMTUwNzAzMDQ1MDAw
WjCBjzEpMCcGA1UEBRMgMmc4YU81d0kxYktKMlpENTg4VXNMdkRlM2dUYmc4RFUx
CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTdW5u
eXZhbGUxFDASBgNVBAoTC1lhaG9vICBJbmMuMRYwFAYDVQQDEw13d3cueWFob28u
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZM1jHCkL8rlEKse
1riTTxyC3WvYQ5m34TlFK7dK4QFI/HPttKGqQm3aVB1Fqi0aiTxe4YQMbd++jnKt
djxcpi7sJlFxjMZs4umr1eGo2KgTgSBAJyhxo23k+VpK1SprdPyM3yEfQVdV7JWC
4Y71CE2nE6+GbsIuhk/to+jJMO7jXx/430jvo8vhNPL6GvWe/D6ObbnxS72ynLSd
mLtaltykOvZEZiXbbFKgIaYYmCgh89FGVvBkUbGM/Wb5Voiz7ttQLLxKOYRj8Mdk
TZtzPkM9scIFG1naECPvCxw0NyMyxY3nFOdjUKJ79twanmfCclX2ZO/rk1CpiOuw
lrrr/QIDAQABo4ICDjCCAgowDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBSmrfKs
68m+dDUSf+S7xJrQ/FXAlzA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdl
b3RydXN0LmNvbS9jcmxzL3NlY3VyZWNhLmNybDCCAVsGA1UdEQSCAVIwggFOgg13
d3cueWFob28uY29tggl5YWhvby5jb22CDHVzLnlhaG9vLmNvbYIMa3IueWFob28u
Y29tggx1ay55YWhvby5jb22CDGllLnlhaG9vLmNvbYIMZnIueWFob28uY29tggxp
bi55YWhvby5jb22CDGNhLnlhaG9vLmNvbYIMYnIueWFob28uY29tggxkZS55YWhv
by5jb22CDGVzLnlhaG9vLmNvbYIMbXgueWFob28uY29tggxpdC55YWhvby5jb22C
DHNnLnlhaG9vLmNvbYIMaWQueWFob28uY29tggxwaC55YWhvby5jb22CDHFjLnlh
aG9vLmNvbYIMdHcueWFob28uY29tggxoay55YWhvby5jb22CDGNuLnlhaG9vLmNv
bYIMYXUueWFob28uY29tggxhci55YWhvby5jb22CDHZuLnlhaG9vLmNvbTAfBgNV
HSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNVHSUEFjAUBggrBgEFBQcD
AQYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADgYEAp9WOMtcDMM5T0yfPecGv5QhH
RJZRzgeMPZitLksr1JxxicJrdgv82NWq1bw8aMuRj47ijrtaTEWXaCQCy00yXodD
zoRJVNoYIvY1arYZf5zv9VZjN5I0HqUc39mNMe9XdZtbkWE+K6yVh6OimKLbizna
inu9YTrN/4P/w6KzHho=
-----END CERTIFICATE-----
subject=/serialNumber=2g8aO5wI1bKJ2ZD588UsLvDe3gTbg8DU/C=US/ST=California/L=Sunnyvale/O=Yahoo Inc./CN=www.yahoo.com
issuer=/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
No client certificate CA names sent
---
SSL handshake has read 1392 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID:
Session-ID-ctx:
Master-Key: 6385A37EF8BA3E886A242E4F835C453BBE6740C2C240BF9C0F80ED7E0586500B87007EB839C57A8E5539C7CF21387C9F
Key-Arg : None
Start Time: 1358267053
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
closed

Items:   6 to 10 of 220   « Previous  | Next »