Posts Tagged ‘security’

Choosing good passwords

Sunday 22 February 2009

passwordAuthentication on personal computers and on the internet is done mostly by using passwords. Other methods are available but for reasons of usability (too complex) and or cost (too expensive) still not widely used. Computer authentication has two goals; one is to keep strangers from using your account in and the second goal to allow you to login. The effectiviness of authentication using passwords is mostly determined by how well you choose your password. A bad password is one that is easily retrievable either by knowing the person (for example by trying spouse or cat name) or by running  a dictionary attack

The recent proliferation of the Conficker worm and the hacking of MySpace showed once again that many people are not very good at choosing a password that is effective. One of the ways the virus spread is by trying to authenticate by using a list of 200 common passwords; the list is public. If your own password is in this list or looks similar to words on this list I suggest changing your password.

Choosing a proper password is not difficult but requires a bit of thinking and creaitivity. Some excellent advice on choosing good passwords from Bruce Schneier. More interesting information on statistical analysis of the passwords used on phpbb.

Advertisements

How secure is SSL

Friday 2 January 2009

https-logoSecure Socket Layer (SSL) is a security technology allowing web clients and web sites to provide a higher level of security for the communication. The question “How secure is SSL?” is relevant this week;  a group of researchers first proved they can forge SSL certificates based on the MD5 hash algorithm. Academically this is very interesting (it is!) but what are the implications in our daily interactions with websites?

Before we explore this question, for the novice some background on SSL certificates. When you visit a SSL enabled site you can see this through the https: protocol identifier in the address bar of your browser. Https enabled traffic gives two things extra, the exchange of traffic is encrypted and cannot be interpreted by some eavesdropping and the identity of the entity operating the web  server is verified. The web browser verifies the identity by a certificate the web server must send to the web browser as part of the https protocol. The certificate consists of an identity, let say ACME corporation, and signature. The signature is created by a certificate authority (Versign is the most well known) that has issued the certificate to ACME after verifying that ACME exists and the entity requesting and receiving the certificate is indeed ACME corporation. The research quoted above shows it is now possibly to generate a certificate that is valid and accepted by the browser without warning without involvement of an official and recognized authority. So any website can successfully claim to a web browser to be ACME corporation, including malicious websites. Technically there are more hurdles to exploit this attack, you need to route traffic to ACME corporation for example, but this is one hurdle less for the visitor. 

The attack is specific for the MD5 hash function, which is already known to be unsafe to say at best. Verisign immediately stopped issuing certificates with the MD5 hash. For reasons I do not understand Verisign still used MD5 based certificates only for the lower class certificates. Most certificates you and I will encounter already rely on SHA-1, a successor to MD5. Extended validation certificates cannot include the MD5 hash.

I argued before that current browsers do a pretty decent job of alarming users about the validity of the certificate presented. An attack using a forged certificate would disable those alarms. However I think most users ignore alarms for invalid certificates anyway. Enough users at least to make a spoofed site with a false certificate just as likely to generate transactions as one with a for the browser valid but sp0ofed certificate. So tools like this blacklist are pretty useless. Which means you and I must rely on other security countermeasures which include:

  • DNS and IP network security, making sure bits intended for site A arrive at site A and not site B.
  • Spam and phishing filters that prevent access via mailed links, the chances of arriving at a spoofed site by manually typing a link
  • Detecting and shutting down spoofed sites
  • Legislation making the risks greater than the benefits.

To name a few. The safest way to be secure against spoofing attacks is not to use the Internet. If that is not an option use your senses, act accordingly, have faith in other measures and assume bad luck on your part if you get involved with a malicious website. 

To round up, does this discovery make us less secure? My answer is no, in fact it makes us more secure because a discoveries like this advance the field of security and drive new innovations that ultimately do make us more secure and b because it forces companies to stop using algorithms which are known to be insecure.

More background and interesting reader comments on Bruce Schneier’s blog.