Posts Tagged security

Registrars and authcodes

Many registrars out there have found different ways to implement Verisign’s requirement of harder-to-guess authcodes for domains by asking to have at least one symbol character (non letter, non number) in the authcode.

This had different effect on different registrars. For example french registrar OVH have implemented it a bit too well, resulting in authcodes like “d*zuW.;2t/!>pHbU”, while others have decided that it wasn’t their problem, and just added a prefix to their authcodes. This is the case for example of GoDaddy, whose authcodes are limited in randomness. An authcode will look like: “S1-AF94C9510BA1C”. Yeah right, “S1-” followed by an uppercase hexadecimal string. I’m pretty sure Verisign wasn’t expecting this when they published the new requirement.

Anyway conditions to steal a domain are pretty much complex (you need to have it unlocked, need to know the authcode, and once transfer is started, the current registrant must not ask his registrar to cancel the transfer for 5 days, and even after the domain is transferred, there are ways to get it back – it’s just more expensive). Stealing a domain is a complex operation which will most likely be followed by legal repercussions.

Best thing to do is to check from times to times in a whois that your domain is really showing your name and address. If not, you might need to do something about it before it’s too late. You might want to consider transferring your domain to a company which cares about you ;) (we’ll even fight your old provider if troubles arise, they can refuse transfer only in some specified cases, as long as you are owner of your domain).

Tags: , , , , , ,

Port knocking, how would I do?

As I saw some articles which seems rather unexact relating port knocking, I would like to add some parts of my own idea about this.

First, port knocking is not meant to be used alone…

Even if you use your daemon’s default port (let’s say port 22 for sshd), port knocking can protect you more than you can even imagine. Let’s take the following setup:

  • SSHd running on port 65122
  • Connections to port 65122 are replied with “connection refused” (via an icmp target rule)
  • In order to “open” port 65122, connection attempts must be made to ports 22448, 44228 and 22884 in this order. Any other order will blacklist the IP attempting to connect for 1 hour
  • More than 5 attempts to connect to port 65122 within 20 minutes will result in 1 hour blacklist

Now, if you’re that smart, just try to find your way in without the “passphrase” (which is 22448-44228-22884-65122). If you do too many attempts, you’ll end blacklisted. Let’s say you found out that port 65122 gets you banned when you connect, and have determined that you can make up to 5 attempts in 20 minutes. Let’s also say you know you have to knock exactly 3 ports to be able to connect.
You then have to test 65536^3 = 281474976710656 combinations, and can only test 5 in 20 minutes, that would require 70368744177660 minutes (133882694 years or so).

I can assume no decent system will be up for 133882694 years without any shift into security settings. You can parallelize that with different source IPs, but it will still last too long against people shifting every 3~6 months.

Tags: , ,

Using SSL keys for client authentification

As you may have seen on services such as MyOpenId, you can either login on your account with a password, or you can generate a client identification SSL certificate and let your users identify with one of the most secure way (as long as they don’t get their keys stolen).

SSL identification?

The idea is pretty simple. Usually communications between a SSL client and server are done via a public/private key system. While I never checked in depth, I assume it’s pretty much like for mails: the client generates a client certificate, connects to the server, gets the server’s public key, sends its public key to the server, then use its own private key and the server’s public key to exchange data.
SSL identification happens there: instead of generating a key, the client will use a previously generated private key, and send its public key alongside a certificate previously obtained from the server. The server will be able to check the certificate, which proves that the client’s key has been signed by the server CA (another private certificate held by the server, only used to make client certificates).

This way, the server will know that the key used by the client was signed by him and can be trusted.

How did this happen? Who gave its key to the client? How can you do the same on your website with PHP? What? Why are you talking about PHP 5.3.1?

Read the rest of this entry »

Tags: , , , ,