200,000 passwords exposed in Sweden

Thursday, October 27th, 2011 | Gene Teo | Comments Off

The Sophos blog always has interesting articles on the latest developments in IT security. It’s easy to read and targeted at non-experts. Today there is a post about how several websites in Sweden were compromised, and an estimated 200,000 usernames and passwords were made public.

The lesson: Don’t use the same password on multiple websites. To help with this, use a password manager like KeePass, LastPass, or even your web browsers’ built in password manager.

Verifying an IIS7 SSL renewal request using OpenSSL

Monday, October 3rd, 2011 | Jim Cheetham | Comments Off

Recently I received an SSL “renewal request” generated by an IIS7 server. These SSL certificate requests are interesting because they are very different from the usual CSRs generated.

The structure of this IIS7 renewal request is actually quite elegant. It seems to start from the premise that because this is a request to renew a *current* certificate, it needs to prove that the request is coming from the correct host — i.e. the host that is actually using the current certificate & ∴ owns the associated private key. In the Internet world, you prove that you are allowed to request renewals for a certificate by authenticating to your CA as the original user, rather than creating a signed CSR.

To prove the right to issue a renewal request, IIS7 creates a normal CSR (PKCS#10 object), and then signs it, and provides the cert of the key that signed it.

  • IIS7 renewal CSR
    • PKCS#7 Data
      • PKCS#10 Data (the ordinary CSR)
    • Normal server certificate
    • Issuing CA data
    • RSA signature (I assume)

Use openssl asn1parse -in iis7rcsr -i to see the structure of the file, and compare this to normal CSRs. You should see an OCTET STRING near the beginning, in an object labelled “:pkcs7-data”, which is what you need to extract to get the CSR.

$ openssl asn1parse -in iis7rcsr -i
0:d=0  hl=4 l=4273 cons: SEQUENCE
4:d=1  hl=2 l=   9 prim:  OBJECT            :pkcs7-signedData
15:d=1  hl=4 l=4258 cons:  cont [ 0 ]
19:d=2  hl=4 l=4254 cons:   SEQUENCE
23:d=3  hl=2 l=   1 prim:    INTEGER           :01
26:d=3  hl=2 l=  11 cons:    SET
28:d=4  hl=2 l=   9 cons:     SEQUENCE
30:d=5  hl=2 l=   5 prim:      OBJECT            :sha1
37:d=5  hl=2 l=   0 prim:      NULL
39:d=3  hl=4 l=2426 cons:    SEQUENCE
43:d=4  hl=2 l=   9 prim:     OBJECT            :pkcs7-data
54:d=4  hl=4 l=2411 cons:     cont [ 0 ]
58:d=5  hl=4 l=2407 prim:      OCTET STRING      [HEX DUMP]:3082096330820...

In order to get the actual PKCS#10 CSR out of here, we need that offset number, “58″ in this example. Then we can use that offset to extract the binary version of that object :-

$ openssl asn1parse -in iis7rcsr -strparse 58 -out thecsr -noout

Next we can read that output file ‘thecsr’ with openssl req, remembering to specify the input format DER.

$ openssl req -in thecsr -inform DER -text -noout
Certificate Request:
Version: 0 (0x0)
Subject: (normal CSR Subject: line, censored)
Subject Public Key Info:
Public Key Algorithm: rsaEncryption

I can wrap all this up into one command-line with no temporary files (but sadly 2 reads of the original cert), as long as I can use Linux’s /proc/self/fd/ to fool openssl (it will do native tricks with file descriptors for password handling, but not normal output).

$ openssl asn1parse -in iis7rcsr -strparse $(openssl asn1parse -in iis7rcsr | grep -A2 ':pkcs7-data'|tail -1|cut -d: -f1) -out /dev/stdout -noout | openssl req -inform DER -noout -text

Certificate Request:
Version: 0 (0x0)
Subject: (Subject: line censored again)
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):

This long command line is directly equivalent to the simple openssl req -in non-iis7rcsr -noout -text that I normally use :-)

So what is it with long passwords

Thursday, August 4th, 2011 | Mark Bedford | Comments Off

It seems that there is a public perception that passwords of enormous length are the safest ones. Apart from being hard to remember and difficult to type, this perception is based upon the an attackers ability to guess the password before the number of failed retries locks the account or someone notices and resets the account. Attackers use computers to compute the passwords (known as a brute force attack) or use a list of passwords (called a dictionary attack) to increase their chance of gaining access to the account. There has been considerable research into the area of password guessing and brute force attacks which has resulted in a number of standards emerging. Standards are generally unable to be modified fast enough to keep pace with the rate of change in technology.  This results in a lower cost for more CPU cycles that are able to calculate or guess the password in a given time period of time.

If people want to have shorter passwords then they can as long as the authentication system is able to adapt. To meet this authentication change the risk profile must be lowered. This is achieved through permitting fewer failed attempts over a shorter period of time before the account is temporarily locked. Being able to detect login requests from multiple IP addresses over the same period of time also triggers the account lock seeing as people are not yet physically able to be in multiple places at the same time. The down side of this is that not all authentication systems have the ability to change their behavior to meet the different risk profiles. But knowing about such options and asking for them will hopefully get vendors and developers to implement such features.