So the talk today is about Dynalogend, which is intended to be an enterprise class two-factor

authentication solution based on one-time passwords. So why would we use one-time passwords instead of just regular passwords?

A lot of spam is intended to go phishing people's passwords, so if people don't use passwords then there's no reason for people to send so much spam in the first place. Many keyloggers with hardware and software are freely available.

Network sniffing is trivial. System tap is another option to expose the passwords. Password recovery is easily abused, especially with social networking sites keeping people's

like family names and their date of birth and everything you need to recover their passwords from other websites. Smart cards are not necessarily for everyone and they require hardware on the computer

that the person is accessing, so it may not always be a solution for an internet cafe or when using a computer in a friend's house or something like that. So one-time passwords are viable solutions.

So I've been looking at this space for a while and I had another look at it last year and the RSA tokens are an obvious solution that many people have seen in banking and

large enterprises, but they're not cheap, they're not free of trade-ins and so on. So it's not something that everyone can access for home use or for small business. Hot fee, on the other hand, is a similar algorithm that is available and freely documented.

It's implemented in various different places, in software and in commodity hardware. So there's a few different software solutions available.

The hot fee toolkit, which is now the birth toolkit, there's another solution called Verada, which is basically a Palm module and an Android app, which provides the soft token.

There's another one kicking it out called Mobile OTP and that started off with another algorithm, although there are variations of the Android app that support both hot fee and the original algorithm. So there's a few different things out there now. What was missing from these solutions?

The database, many of them are based on flat files, they're very simple management of the data. Privileged separation, they're genuinely secure environments.

You have a hardware security module, you have the key data kept on a separate network device with firewalling in place and only a limited amount of traffic can interact with that device. So having a Palm module on every Unix box in a network,

having a copy of the secrets on every Unix box on the network is less than ideal. And that was the intention of modularizing things. Modular use cases, so enabling technologies like OpenID, Radius, J2E, web applications.

The existing solutions provide the PAM solution, which is good for Unix logging, but there's a range of other applications, many of them web-based, where people need this sort of security and they need to have it in a convenient form.

The provisioning and lifecycle management for the users and their keys, that's also something that's not addressed at the moment in any of the tools. Most of them are quite basic, they implement the algorithm and they can handle the keys,

but they don't provide a complete framework to the system administrator. So Dynalogging aims to fill the gaps identified in those other existing products,

to provide a stable foundation for further algorithms like time-based OTP. The existing solution is event-based, so you press a button to get a new password. The time-based solutions are revolving by themselves over time,

and they can be added into the infrastructure. Something that just works, that a sys admin can drop in, and that they can expect it to provide a minimum level of security on the box, or their network. So the current status of the project, the Unix ODBC support is there,

so it can be used with a range of databases. No tools are provided yet to manage the data, but nonetheless having the data access there enables that next set of work to commence.

It implements the HotP algorithm, but not the other algorithms like TopP. And it has OpenID, fully functional, using the PHP MyID solution.

And that's just been patched to integrate with the backend. This is a diagram of the whole architecture. So at the top of the diagram, this half is the server side. So in an ideal solution, that would be a separate box on the network with a firewall,

and these would be running on various client boxes. So this might be a web server in a DMZ, and this might be a more secure server that's further back from the DMZ.

You could run them on the same box if you wish to do so. TCP is used for communication. The protocol used between the applications and the server resembles the SMTP command set.

So this application will send a command, and this will send back some kind of a response code to indicate whether it was accepted or not. So it's very basic right now. Up at the top here, you've got various modules for storage, for storing the key data, which needs to be protected.

You've got a controller section that decides which modules to talk to, to get the keys and then to select an algorithm. And over on the right, you've got the different algorithms. There's only the first one being implemented so far.

Also, the PHP MyID is the only client-side solution at the moment. The next step is to implement this C client that can then be dropped into other code, such as a RADIUS module or a ARM module or some other client.

So the directions for the project are to finalize the network protocol. So the protocol at the moment is very basic. The potential is SMTP. One thought that I've had is to use a message format more like a SIP message or an HTTP request with headers,

so that additional data can be passed back and forth, maybe for logging purposes. So to generalize it to provide multiple algorithms is the single algorithm at the moment is hard coded.

And configurable routing. Over-authentication requests. So that you can, as an administrator, you can choose which users will get which algorithms and in which scenarios. So you might have one level of security for OpenID and you might have another level of security,

like selecting a challenge response scenario for doing e-commerce transactions. And logging. In an OpenID situation, the OpenID server will know every time that the credentials are used with a different website.

So the names of those other websites could be captured in a log. There's no such facility at the moment. But logging could be implemented to capture some of this data, so the user can then go back and see where their credentials were used.

And finally, the packaging and making it available in distributions. It's not quite at that stage yet. Just to go into more detail on the routing of the requests.

In the diagram we looked at before, you could see the different backend storage options and the different algorithms. With the challenge response algorithms, the challenge can be used to form a signature.

So the server can send some known data, such as an account number or the size of a transaction, as part of the challenge. And when the user enters their code, they start with that challenge, they put that into their token.

The token gives back the code that signs that transaction data, such as the amount of the transaction. So when that type of activity takes place, the dynlogging infrastructure could send some sort of a message out to another application on the server side.

And that could be done through a queue or through some sort of messaging protocol used in the backend. And there might be a range of systems that people already have that they want this to drop in with.

So we'll go on to a quick demo in a moment. So I'll just put a final slide in here and come back to my mouse here.

So this is the Android client that I prepared for the dynlogging. And you can find this in the market. Has anyone already downloaded it? Or does anyone have an Android phone?

You can find this in the Android market for dynlogging. So what we'll do, I've set up a user on a database down here.

So one of the drawbacks of passwords is if you put your password on a slide, everyone goes away with a copy of it.

Anyway, that's my user. So if you have the app on your phone, you can configure it with this password, FUBAR. And we'll do that now. Let me just go into profiles, the add profile.

So we've now got our profile set up on that password. So that's the first code for that user. So let's try accessing the OpenID provider using this user name.

I've already got a copy of the, that's the OpenID URL for this user.

What we'll do is add the OpenID there.

So we now associate this OpenID with this account.

We now get asked to authenticate. This is coming from the OpenID provider itself. And we just take our code, which is here, 734211.

And that's now authenticated. So if we log in again using the OpenID, that's the same OpenID there, the login.

And it just goes straight in because there's already a session cookie in this browser from when we entered the code. So we can now float around on different websites and using that session cookie. The PHP script would be modified to periodically prompt for the code again.

So the user would have to go back into their token and generate a new code from time to time. And that would increase the level of security. There's a range of permutations on that that can be implemented to achieve the level of security that a business company is comfortable with.

So at this stage, does anyone have any questions about the technology?

Just wait for the door to close. In the current setup, in order to function, the device you're using to send a request from the central server, it has to be connected in some way to the network, right?

To the internet, for example. Is there any kind of offline solution that can be created? Like the Macs are using the tokens? The soft token does not need to be online. When you run the Android app, it does not need an active internet connection.

When you install this application, it will give you a warning about network access. And that's because I'm implementing a registration scheme for user lifecycle management. That's not complete yet, so you won't see that anywhere in the UI.

At the moment, there is no network communication between the token on the phone. And the server. So the token on the phone is generating the codes using an algorithm based on the seed that was configured.

So when we configure the profile, we put in this secret. And the server has the same secret in the database.

And so they're both using the same secret to calculate the secrets of codes. So there is no communication between the server and the token. And it is possible to have the...

These are some of the hardware tokens that are available. Has anyone seen these? Pass them around. I can't pass mine because they were pressed several times so people don't press yours.

You shouldn't care. After they are being pressed, it's not the same. The first one is event-based. It means that the code remains valid until you use it. If you press it in the morning, it's valid 10 days afterwards.

Until you use it, the second one is time-based. It's only valid during 60 seconds. So it's better to have a valid token during 60 seconds because you're less vulnerable to man-in-the-middle attack. Because the attacker only has 60 seconds to connect.

So where does it get time from? Does it get time off the radio? No, no. These tokens have very good synchronization. And they work for an average time of five years.

They can be pressed 100,000 times. And they cost around 10 euros, maybe less for some time. So it's a very nice solution. Please close the door. So just to finish it, we have some light entertainment, but also a very meaningful message about why this is important.

So in 2006, I had the pleasure of submitting evidence to the House of Lords in the UK.

And they were investigating the full gamut of security risks presented by the Internet. And everything it means for the individual consumer.

And I chose to focus on one simple topic, on why passwords are bad. And I gave them a very thorough briefing on that. How long ago did you say? 2006. They didn't read it.

They still didn't read it. And even in, they didn't tell their friends in Washington either. They obviously weren't reading it.

So, but there are some people who have been paying attention. This was in the news today. That biking gangs in Australia, that motorcycle gangs have been using blackberries to encrypt their communications. So we have a bizarre situation where potentially the next leader of the United States has been using Yahoo.

While you have motorcycle gangs in Australia using highly secure blackberries.

So that's it for today for long time passwords and tokens. Unless anyone has any questions. I have a question. Where can you get these kinds of tokens? 10 euros or less.

From gooz.eu this is my website. This is our website. So www.gooz.eu.

Do you have it? What if I generate 10 holes on my phone and I try to log in with cloud. You have a window.

The default window in the protocol is 20 codes. So if someone presses the button 19 times then that's okay. They can still use the next code. And if they press the button 50 times the system will not recognize the next code. Because otherwise you have a very high risk of someone generating a random code that happens to be the next code.

So it has this window of 20 presses of the button. If you lose synchronization because you advance your token far beyond the counter on the server side. There is a protocol for resynchronizing.

In the specification it suggests that would involve submitting two consecutive codes. And you may also choose to have some other security check when you do that resynchronization. And that would be up to the administrator to decide how the user could resynchronize their codes.

A similar algorithm could be used for the initial user registration as well. And if they receive a token by post. I wanted to ask a question. How do you plan to protect the seeds in future versions?

Because people consider that using this OTP password is great for users. But you have to consider that once in a while someone may connect to your computer or try to access the seeds.

Are you thinking of a way to encrypt the seeds or use an encrypted database like PostgreSQL? Ultimately if you encrypt the seeds, this is not like a public key solution. It would be symmetric encryption. So the problem you would have is the server still needs to decrypt the seeds before performing the algorithm.

So someone who has root access on the server or who walks away with the server hard disk will still be able to get the password and decrypt all the keys. Unless you had a situation where the operator has to manually put the password in when they boot the machine.

Would it be possible to use something like this Stanford remote protocol? SRP protocol? I'm not sure. Can you tell us more about the protocol?

As far as I know you can do a hashing operation on an encrypted value without having to encrypt it on the server.

That would not be the same as the HotP algorithm. To implement the HotP algorithm you need to have the unencrypted secret to perform the algorithm. So the principle of security in this system is that the machine that has those secrets should be kept in a secure location behind a firewall.

The only port that should be accessible is the port for performing authentication. When the authentication is done, the token code submitted by the user is sent in to the server over that TCP connection and the server sends back a yes or a no.

The secret is never released by the server. So the minimum amount of data is exchanged to perform authentication. Do we have other questions? Just one remark is that there is a secret seed on his server, but as a seller, as a producer of tokens, I also have the seeds.

Because when you buy the tokens, I ship them to you. So what we do is that we have security, a security room with a security server with no access to encrypted routes. And we ask you when you buy the seed how long, how long time you want us to keep the seeds.

So we can destroy the seeds right after shipping them to you. We can keep them three months because sometimes you'll lose the seeds or we can encrypt them using PGP. And they are kept, in this situation, they are kept on a server that is not connected to the internet.

Okay, thanks a lot.