• Your Username
• A hardware device that shows a pseudo-randomly generated PIN number which changes every minute or so.

‘Cos the PIN is a pseudo-random sequence, if the token and a server are in sync, you can validate that someone has read that token inside the last minute. It’s an expensive technology - but neat!

The idea is the same as, say, a credit card. More than just saying who I am and that I have some piece of knowledge (e.g. my PIN number), I also have to have a physical object which is hard to duplicate (my credit card). This should make my identity more certain.

Anyway, how does this fit with SharePoint?

The short answer is, it doesn’t. This technology works with and ISA server/Firewall, which is well in front of any SharePoint system. Obviously, this doesn’t stop you using it, but it does mean that you have to log in twice - once to get past the RSA security on the firewall or ISA server, and then once to log in to SharePoint - though this second part is almost more so that SharePoint knows who you are.

Still, it’s easy to imagine that single sign-on would be desirable - is it possible? Well, I found these excellent posts by Pranab Paul:

• SharePoint 2007 (MOSS/WSS) FBA and RSA - Unanswered Questions
• Using HTTP Module for SharePoint 2007 (MOSS/WSS) site using FBA And RSA

(Note: this is backwards - it makes more sense this way around!)

The short in-case-his-blog-vanishes description is that the RSA system adds an RSA cookie to the HTTP Request after the user has been authenticated. Pranab had a database of SQL database of the external users with the same name as sent by the RSA system, so he picked up the username from the RSA cookie, and logged the user in!

Now, this did slightly nerd log-out (which would automatically log the user back in), and ’sign on as a different user’, so his second post details an HTTP module to handle this (i.e. remove the RSA cookie for the signout/access denied pages).

Very cool. Unfortunately, I’m not convinced the customer will go for this when they realise that it means that external users will need some hardware token to gain access. Yeah, I know, that’s the point, but you can see the ‘but I want access and I left my token at work/home/in the car/bath, etc.’.

Finally, some more links:

• Walk-through for RSA SecurID Authentication for ISA Server 2006 Part 1
• Walk-through for RSA SecurID Authentication for ISA Server 2006 Part 2

Parts 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14

To me, the problem is one of failure of KISS (Keep It Simple, Stupid). Applications and protocols haven’t been, and we’ve had more tacking together of technologies, and expansion of complexity of everything.

I mean, consider what languages you needed to know 10 years ago, and now:

Then:

HTML 3.2, JavaScript maybe, Perl if you’re brave, SQL if you’re a hero.

Now (Microsoft Stack only):

HTML 3.4, 4 (various favours), XHTML, XML, XSL, XPATH, JavaScript (much more complex), ASP.NET 2.0, C# or VB, .NET frameworks 1.1, 2, 3 and 3.5 (soon), ADO, SQL, CSS, ‘AJAX’

That’s just the languages and base technologies - never mind getting into a higher level of software (e.g. SharePoint). Or non-MS technologies - Ruby, Rails, Python, Java in various forms…

It’s similar in protocols…

Then:

HTTP, HTTPS, FTP, SMTP / POP

Now:

HTTP, HTTPS, FTP, SMTP / POP, SOAP, Web Services (plus various extensions), IMAP, Various Peer-To-Peer protocols, Various Instant Messaging protocols

(Yes, those are fairly high level, and from different levels of the stack - but still, you’re expected to know about them.) (And yes, I suppose you’d need to know a bit about TCP/IP and IPSEC)

Does that sound simple? Does my granny skateboard?

(Well, no, but that would be so cool).

Security will be impossible with such a complex, varied stack of technologies, and developers simply won’t be able to specialise enough to know how to make secure enough applications. It alarms me how wrong people are getting password storage alone - I mean, this stuff has been known since the 70’s. If they can’t get that right, how will they manage with a such a deep and varied set of tools?

Thus, I decided to benchmark the Symmetric alogrithms in the .NET Framework - DES, Triple DES, RC2 and Rijndael. To make life interesting, I thought I’d try them with differenct key sizes and block sizes, and cipher modes.

So, I’ve linked to definitions of these factors, but for those who don’t want to read vast chunks of Wikipedia, here are my (simplified) definitions. For anyone really interested in learning how to program with encryption properly (and in learning why their 128 bit key probably isn’t 128 bits strong) I can strongly recommend the book ‘Practical Cryptography’ by Bruce Schneier and Niels Ferguson.

Symmetric ciphers are ones like you used when you were a kid. You have some operation that turns a message into garbage, and then the reverse of that operation turns that garbage into a message. Some algorithms don’t have a reverse - they are asymmetric ciphers, and are a whole different kettle of fish.

Keys are the password you use with your cipher. For example, if you’re cipher as a kid was to shift all letters in the alphabet, then the key might be the numbers of characters shifted. Big keys are harder to break. Think of it as being just like a password or PIN number. If I tell you that my PIN is 4 digits, you might be tempted to guess all 10,000 possibilities, and on average you’d figure my PIN out after 5000 tries. If my PIN was 8 digits, then there is 100,000,000 options - and you’re less likely to try all the possibilities, eh?

Block sizes. Well, okay, some ciphers work on blocks of data, rather than each byte (or each ‘letter’). These are block ciphers. There are also stream ciphers, where each byte is encrypted one by one. Anyway, in block ciphers there is a limit to how much data can be encrypted without ‘leaking’ information. Larger block sizes can encrypt more data without that leakage. (That’s not to say that the block has been decrypted, but an attacker could start to learn things about the contents of that block.)

Cipher modes don’t really have a parallel with how you did codes as a kid. I guess I would describe it that if the cipher is about how you make an apparently random set of bits, then the cipher mode is about how you then use them. There are lots of different modes, but the .NET framework classes only seem to support 3 - ECB (Electronic Cookbook), CBC (Cipher block chaining) and CFB (Cipher Feedback).

So, what are the algorithms:

• DES - An old encryption standard, now regarded as offering poor security, but so widely used that it is still in operation as a legacy system.
• Triple DES - An improved version of DES, made by essentially applying the DES 3 times.
• RC2 - A moderately old encryption algorithm. Flexible key lengths, but short block size.
• Rijndael (aka AES) - The latest encryption standard. The Rijndael algorithm was selected from several as part of a competition. It wasn’t regarded as the most secure, but it was quite quick. The Advanced Encryption Standard (AES) is actually a subset of Rijndael.

The Test

I found a nice text file - “The complete works of Shakespeare” - as my test data.

For each algorithm, for each mode, key and block size, the test program encrypted and decrypted the data twenty times, and reported the average ‘time’ for each operation. I was using the Win32 QueryPerformanceCounter function, which doesn’t really return a time so much as cycles. However, all the tests were done on the same machine, so they’ll do just fine for comparison purposes.

Results

With the several factors tested, there are many ways of slicing the data. It’s worth noting that these results are pretty rough, as the times taken also include file IO operations, and with any modern PC there’s also something else happening at any single time. Also, the times are the total time taken to encrypt and decrypt, which might not be the same for each operation. Treat the results as a loose guide.

First let’s look at the raw results. You can get the results here (Excel file).

Unsurprisingly, DES is fastest - given it’s age, and the low level of security it offers now. Triple DES with the longest key it supports was generally slowest. RC2 covered the full range of results, which is also unsurprising, given it’s flexibility, and Rijndael sort of falls in the middle.

The first thing I noticed was how few tests there were using DES or Triple DES. RC2 and Rijndael are much more flexible in their use.

Next, it’s interesting to note that RC2, DES and Triple DES using Cipher Feedback Mode (CFB) were all very, very slow. They all seem to suffer very badly using CFB.

So, excluding the CFB results then (as they are so exceptionally slow), what do the other results show? Well, Rijndael does not suffer so badly in CFB, although CFB is slower.

ECB appears slightly slightly faster in the table, though examining the CBC Mode Graph shows little difference.

To compare the modes, I looked at just the operations done with the Rijndael cipher.

Again, we see little difference between ECB and CBC, so I guess there’s no reason not to use the more secure CBC mode over ECB (for an example of it’s weakness see here). Also, for 128 bit blocks (as required by the AES standard), CFB is as quick as ECB.

Rijndael is not great in CFB mode with blocks of longer than 128 bits.

Okay, so let’s focus on just one mode (CBC) and look at the results shown in the CBC Mode Graph. Well, it’s interesting to note that RC2 with a 112 bit key was quite quick - faster than with some shorter keys. However, it’s only about 6.5% longer to use 128 bit Rijndael - which is a key that is 14% longer. Doubling the key with Rijndael to 256 was only 10% longer than 128.

Longer blocks take longer to encrypt and decrypt. 64 bit blocks seems a little short these days, only being safe for up to a couple of hundred megabytes. 128 bits seems more reasonable. 256 bits seems excessive. Rijndael seems to have little penalty for using 256 bits over 128, though if you do, you’re not using an AES standard encryption.

Conclusion

DES and Triple DES are old. DES isn’t secure, and Triple DES doesn’t seem to offer much given Rijndael and RC2 being much faster than it.

In terms of cipher modes, these classes only seem to support ECB, CFB anc CBC. ECB is generally regarded as being a poor mode - it’s not very secure. CFB was typically slower than CBC, and as Microsoft have already implemented the classes, some of the advantages CFB (i.e. encryption and decryption being identical operations) have been lost.

So, then examining Rijndael in CBC mode, well, there is little penalty for using 256 bit keys or 256 bit blocks. However, it’s probably worth sticking to 128 bit blocks as 1) it is plenty, and 2) it is AES compatible.

All in all, I was surprised by how similar a lot of the results were for different algorithms, and I was surprised by how slow some of the CFB mode operations were.

To be honest, I can’t really think of a reason not to use Rijndael with 128 bit blocks, in CBC mode. Unless time is a really critical factor, 256 bit keys are stronger. Finally, the RijndaelManaged class in the framework is a managed class, rather than a wrapper for a COM object.

So, the winner is Rijndael!

Comments from my old blog:

This is a very informative article. I have just started looking into encryption, and I have come across nothing on the internet that is as concise as your article.
Will you be doing something similar with asymmetric encryption as well?

By Firoz at 06:22:04 Friday 9th February 2007

Yup, well, at some point. The truth is, in the .NET 2.0 framework, there isn’t a lot of other asymmetric algorithms. RSA is about it. I think in the .NET 3.0 framework there is elliptical curve, and that would be interesting…

So, yes, when I get around to it.

By Andy B at 10:09:43 Friday 13th April 2007

The short of it is:

Essentially, if you want to use RijndaelManaged as AES you need to make sure that:

1. The block size is set to 128 bits
2. You are not using CFB mode, or if you are the feedback size is also 128 bits
3. The key size is 128, 192 or 256 bits (Added by Andy)

I started getting an error though - “Key not valid for use in specified state”. Odd. I was importing the key from an XML file, using the FromXMLString() function. It all seemed to work just fine. So, WTF? It’s not like the code is complicated:

RSACryptoServiceProvider rsa = new RSACryptoServiceProvider();
rsa.FromXmlString(publickey);
byte[] encryptedData = rsa.Encrypt(data, false);

So what gives?

Well, eventually, I tracked it back to this - I was trying to send too much data. Not very much - less than a couple of hundred bytes - but this was too much.

The obvious thing to do was change the way this works to match the way it’s supposed to work - use RSA encryption to transfer the key to a block cipher, and then encrypt all your data with that block cipher. But I couldn’t be arsed - I just wanted to see the asymetric encryption work - so I reduced my data…

Comments from my old blog:

Sounds like you where in the 70-536 Self Study book from Microsoft. In chapter 12 doing some suggested practices.

Anyway.. that’s where I am and your message here on the blog helped.

I too will send a smaller file

By Micke at 17:13:02 Monday 24th September 2007

Yup, I think I was. It was a bit daft that they didn’t mention the limits on the size of the data.

But that book has a _lot_ of issues.

By Andy at 10:18:03 Thursday 27th September 2007

Comments from my old blog:

What about Search Engine’s spidering it? Of course you’ll want to include a <META NAME=”ROBOTS” CONTENT=”NOINDEX, NOFOLLOW”>, but even then, I’ve read that certain search engines like askjeeves.com IGNORE those tags.

Brandon@Cstone

By Brandon@Cstone at 04:12:01 Thursday 29th September 2005

Well, I guess as you say it’ll have to be for urls that aren’t linked to anywhere. The URL itself is sent out by email in the example. That’s my guess anyway.

By Andy at 21:43:46 Saturday 19th November 2005

So I’m a nerd for security, and I do like overkill, but there are some simple things that could be done to improve the security described in the ‘Weak Passwords’ section on page 2.

First off, don’t use MD5. It’s broken , or at least it would be better (and very little effort) to use SHA-1.

Second, if you’re storing the hash (MD5, SHA-1, SHA-256, whatever) of a user’s password, well, don’t just hash the password, but hash the username too. PHP’s Crypt() function is for this kind of thing, with a ’salt’. E.g.
Function EncryptPassword( $username, $password ) {
$salt = substr($username,0,2);
return crypt($password, $salt);
}
What would this mean? Well, an attacker trying the dictionary attack described would need not 1, but 3844 dictionaries, assuming usernames are alphanumeric and case sensitive.

Hell, why not use the username too as what you’re hashing? I’ve not seen this done anywhere - and I’m not sure of it’s security (I say that in the most paranoid sense) - but principle is the same. By appending the username to the password being hashed, well, you’d need a seperate dictionary for each username. You could even throw in a constant string - it doesn’t add much security, but it means your code would have to be compromised in order to allow precomputation of a dictionary for a user.
Function MakeHash( $username, $password ){
return sha1( $username . "some arbitrary string" . $password);
}
A final thought - don’t underestimate passphrases rather than passwords. They’re easier for people to remember than passwords. Consider ‘r5GG8%’ and ‘elephants lollop gracefully’. Which would you remember? Robert Hessig of Microsoft PSS has a good article. And all of the above techniques would work with a passphrase instead of password - after all, they’re all just text…

Comments from my old blog:

DES was broken many years ago, so that’s a very poor alternative to MD5.

By Chris at 16:18:01 Saturday 30th July 2005

Puzzled by the DES comment - DES isn’t a good algorithm for encryption, certainly - it’s bust, and we have AES now. Also, DES is a block encryption cipher, whereas MD5 is a hashing algorithm. Different things.

By Andy at 21:50:29 Saturday 19th November 2005

I believe the DES comment is because your EncryptPassword function passes crypt a two character salt, which makes crypt use the ’standard DES-based encryption’.

By Deebster at 16:41:44 Wednesday 29th March 2006

Ah, well I’ll be damned. I hadn’t realised that Crypt could use DES. Come to that, I’m not sure why I’m using a Crypt function for what should be hashing. Brain fade, I guess. I suppose that replacing DES with Blowfish would give a function that encrypted the password in a recoverable way, although I’m not a fan of that.

By Andy at 12:28:55 Saturday 6th May 2006

An interesting validation technique

Encryption in Javascript. I’m sure I’ll think of a use eventually, but it just seems a neat idea to link with Ajax philosophy. I mean, with AES and the like, you can get the user to enter password, and there are uses for symmetric key algorithms.

So, here is a neat idea - scramble the buttons you need to input for each session.

From Bruce Schneier’s Website

If you own the box, you have mouse clicks, yes, but are you recording them? And are you also recording information about what’s being written to the display?Here’s something encouraging: my bank, Shinsei (www.shinseibank.com), requires an account number, card PIN and password for authentication to their on-line banking. They offer the option (in fact, it used to be the only option) of using the “secure input keypad” when entering your PIN. This pops up a new window with buttons from zero to nine that you click with the mouse. Even better, the buttons are placed randomly every time.

I was pretty surprised to see this coming from a bank, though they are well known for having very good IT guys.

Posted by: Curt Sampson at April 4, 2005 08:35 PM

I found an article at JavaWorld that gives an interesting, albeit slight confusing, approach. I made some notes based on that here, and offer some slight improvements.

To state the problem - a user (Alice) logs in to a website, does whatever, and logs out. Another user (Eve) comes along an presses the back button; the web application should not show any of the pages from the Alice’s session (or indeed, the site) until the next correct login is given.

There are three aspects to this - preventing cacheing, forcing login, and preventing Login from a stored page.

Preventing caching is straight forward enough - you send the appropriate headers, expiry dates, etc.. That’s not very interesting - look it up somewhere else…

Likewise, forcing login isn’t all that interesting. You’ll need some sort of session mechanism (most worthwhile language have LOTS of help with this), so for each session, you simply store whether the user is logged in. If not, take them to the login page. Do that for each script that you want restricted. Not very hard. Servlets can have all sorts of security configured in the Web.xml file, so it’s straight forward enough to protect pages.

But, this is where it gets more interesting - what if Eve presses the back button until she gets to Alice’s login page?

It’s worth considering what happens when the back button is pressed. If a page was requested using GET, then it is shown. If a page has Post data, a message is displayed - something like

Warning: Page has Expired
The page you requested was created using information you submitted in a form. This page is no longer available. As a security precaution, Internet Explorer does not automatically resubmit your information for you.

To resubmit your information and view this Webpage, click the Refresh button.
If Eve then hits refresh, she’ll be logged back in - as Alice. This is not desirable.

To prevent this, the login page should contain a hidden field - the System Time of the server when the login page was served (we’ll call this SysTime). In the database, the User record should have a field of when the user last logged in (we’ll call this DBTime). For a login to be allowed SysTime must be later than DBTime. If the login is allowed, the DBTime is updated to be SysTime.

Naturally, you also want to do all you usual user authentication - valid username, correct password, etc..

Great! Now, what if someone tries to spoof the SysTime value? What if they create the HTTP request using the user’s username and password, but another time?

Well, to prevent that, don’t serve the time, but the time encrypted. Use a block cipher - that is a simple one, with one password to encrypt and decrypt. And also store with the time the session ID. By the time you’re trying to authenticate, the session should have been initialised. Consequently, the value of the hidden field will be a time, encrypted, that is specific to that session.

When the form is submitted, unencrypt the hidden field. If the session ID stored in it and the ID of, well, the session don’t match, someone is trying to spoof the session. If they do match, but the SysTime value is older than the DBTime, then this is an old login. Otherwise, it is a true login, and let the user in.

Note:

Spoofing the Login Time - Can’t be done! It’s encrypted, and specific to that session.

‘Down Time’ due to client machine being on a different time - Doesn’t matter! It’s the SERVER’s time that matters, the client can be in NeverNeverland time as far as the server is concerned.

‘Down Time’ due to daylight savings time changes - just always use a fixed time reference, such as GMT.

A guy I work with had been asking about how to figure out the entropy of a password. This is, put simply, measuring the disorder of a password - the more disordered, the harder it is to predict. And this is very hard to do, for reasons I’ll explain some other time.

Anyways, we then discussed passphrases. Instead of being a word like ‘Bgc4$4q2′ or something equally obscure, you use a phrase that would be difficult to reproduce - ‘Eat flying doughnut on Thursday’. This is still difficult to figure out the entropy for - you could choose an easily predicted password (e.g. ‘In the beginning God created the heaven and the earth’) - but is generally more secure.

So this morning I read a fascinating article by a guy from Microsoft PSS Security about passphrases. Worth a look for all techies, certainly I’ll be looking at using passphrases from here on.

I’ve also just read an article about how authentication never expires in e-commerce sites. An interesting point - it should be possible to terminate accounts on e-commerce sites. I mean, if you don’t, if the account is still valid, then your details could be used. But I can’t say that I know of a way to go to Amazon and tell them to disable my account.

I guess one option would be that if an account just hasn’t seen any activity in a while, you send out an email warning of it’s impending shutdown. If there is no response, close it down. Not perfect, but you’re making the window for the abuse of that username/password smaller.

And lastly, there is an article on why secret questions are a bad idea for password recovery. Basically, it’s the old ‘Security is as good as it’s weakest link’. Never liked these things anyway.

The realm tag I used was:
<Realm className="org.apache.catalina.realm.JDBCRealm" debug="99"
driverName="com.mysql.jdbc.Driver"
connectionURL="jdbc:mysql://localhost/jtest"
connectionName="root" connectionPassword="password"
userTable="tusers" userNameCol="cUser" userCredCol="cPwd" userRoleTable="troles" roleNameCol="cRole"/>
Naturally, this requires the MySQL JDBC driver from Mysql.com. Download it, and place it into the $Tomcat\common\lib directory (still with me?)

Careful that you actually enter the correct password - some idiots try to configure the JDBC connection with the wrong password

Next up, set up some tables in MySQL:

Table tusers:
+-------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| cUser | varchar(32) | | PRI | | |
| cPwd | varchar(32) | | | | |
+-------+-------------+------+-----+---------+-------+

Table troles:
+-------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| cUser | varchar(32) | | MUL | | |
| cRole | varchar(32) | | | | |
+-------+-------------+------+-----+---------+-------+
And populate with data:
+-------+-------+
| cUser | cPwd |
+-------+-------+
| Alice | bingo |
| Bob | chuck |
| Eve | daily |
+-------+-------+

+-------+-------+
| cUser | cRole |
+-------+-------+
| Alice | user |
| Alice | admin |
| Bob | user |
+-------+-------+
So, we’ve got our user and role tables set up, Tomcat configured to query it - only 2 more essential components to configure. What, you ask, with baited breath. (Actually, would baited breath not smell? I digress…)

We need content to apply our permissions to, and a web deployment descriptor (web.xml) to describe the security applied to these resources.

I created 2 html files. That’s right, just HTML, not servlets, not JSP, just static html. I created user.html and admin.html :
<html>
<head><title>UserAuth</title></head>
<body>User Perm Authenticated</body>
</html>
Admin.html is the same, just with ‘admin’ where it says ‘user’.

In my $Tomcat\webapps directory, I created a new directory ‘test’. Beneath this, I created a directory ‘html’ and I put the html files in there. It just seemed like a good idea, though I guess you could stick it under the root - just you’ve have to specify a different <security-constraint>. See below, you’ll get what I mean.

I also created a WEB-INF directory for the web.xml file. I then wrote my web.xml file:
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">

</web-app>
Things to notice - I have seperate <security-constraints> for the two html files, though as it is a pattern match on the path, you don’t have to. And I have two roles, user and admin.

That’s it, really. Try going to the path for each of the files and logging in as Alice, Bob and Eve. ‘Nuff said.

Only of interest to geeks, but quite clever really. You can even specify the MessageDigest algorithm used to hash a password. Will have a play and see how well it works…