 So the talk today is about DynaLogin, 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. So you can expose the passwords. Password recovery is easily abused, especially with social networking sites, keeping people's family names and their date birth and everything you need to recover their passwords from other websites. And the 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 the computer as 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. I had another look at it last year. And the RSA tokens are an obvious solution that many people have seen in banking and other large enterprises. But they're not cheap. They're not free of patrons and so on. So it's not something that everyone can access for home use or for a small business. POPPY, 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 modern hardware. So there's a few different software solutions available. The POPPY tool kit is now the OTH tool kit. There's another solution called Parada, which is basically a panel module and an Android app, which provides the soft token. There's another one kicking it back called Mobile OTP. And that started off with another algorithm, although there are variations of the Android app that support both POPPY 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. Privilege separation. In a genuinely secure environment, you'd have a hardware security module. You'd 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 PAM 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. And 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 life cycle management for the users and their keys. That's also something that's not addressed at the moment in any of the tools there. 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 in Australia. So Dynalogin 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. But time based solutions revolve in and 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 in 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 OTP algorithm, but not the other algorithms like OTP. And it has open ID, fully functional, using the PHP MyID solution. And that's just being patched to integrate with the backend. So 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 the top here, you've got various modules for storage, for storing the key data which leads to be protected. You've got a controller section that decides which modules to talk to to get the keys and then to select the algorithm. And over on the right, you've got the different algorithms. There's only the first one, the OTP 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 AM 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, it resembles SMTP. One thought that I've had is to make it use a message or map 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 our code and configurable grouping of 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-bomber transactions and logging. In an OpenID situation the OpenID server will know every time that the credentials are used with a different website. So that 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 the status of the user and then go back and see where their credentials were used. And finally the packaging and making it available in distributions and 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 we 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 the transaction that's part of their 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 Dynal logging infrastructure would 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've just put a final slide in here and come back to my mask here. So this is the Android client that I've prepared for Dynal logging. And you can find this in the market. Has anyone already downloaded it? Does anyone have an Android phone? You can find this in the Android market for Dynal logging. So what we'll do, I've set up a user on a database down here. It's one of the drawbacks of passwords is if you accidentally put your password on a slide your phone goes away with a copy of it. And anyway, that's my user. So if you have the app on your phone you can configure it with this password foobah. And we'll do that now. I'm just going to go into profiles. So we've now got our profile set up on that password. So that's the first code that user. So let's try accessing the OpenID provider using this username. And CostM1 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. We log out of that. We can log in again using the OpenID. So that's the same OpenID there. 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 using that session cookie. The PHP script could be modified to periodically prompt for the code again. So the user will have to go back into their token and generate a new code from time to time. And that will increase the level of security. So there's a range of mutations on that that can be implemented to achieve the level of security that are in this code is comfortable with. So at this stage, does anyone have any questions about the technology? Just wait a minute. The current setup, in order to function the device you're using to send a request to the central server, it has to be connected in some way to the network, right, to the internet. 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 the 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 seeds 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 user some of the hardware tokens that are available. So has anyone seen these or passed them around? I can pass mine because they were pressed several times so people don't press yours. Okay, you can get a good idea. Okay, because after they are being pressed, it's not the same. The first one is even 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 like that. Because the attacker only has 60 seconds to connect. So when do they get time from it? Does it get time off the radio or entity? No, no, these tokens have a very good synchronization. And they work for an average time of 5 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 and we're very impressed. Please close the door. 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 or 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. Bicycle gangs in Australia, 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. That's it for today. One-time passwords and tokens. Unless anyone has any questions. Where can you get these kinds of tokens? 10 euros or less? From Goose.eu. This is my website. So www.goozz.eu. I have a question. Do you have it? Yeah. What if I generate 10 volts of my phone and I try to log in with... 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 at the button. If you lose synchronization because you advance your token far beyond the counter on the service, 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. That would be up to the administrator to decide how a user could resynchronize their posts. A similar algorithm could be used for the initial user registration as well. And if they receive a token by post... No, no, it's okay. Finish. I wanted to ask a question. No, go ahead. How do you plan to protect the scenes in future versions? Because, you know, 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. So are you thinking of a way to encrypt the seeds or use an encrypted database like from the squirrel? Well, 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 would still be able to get the password and decrypt all the keys. So you had a situation where the operator has to manually put the password in when they group the machine. And what was the question? Wouldn't it be possible to use something like this as a stand-for remote protocol? This SRP protocol, what has been on the distribution? I'm not sure. Can you tell us more about the protocol? As far as I know, who exactly can do a hashing operation on an encrypted value without having to decrypt it on the server? That would not be the same as the hot pay algorithm. To implement the hot pay algorithm, you need to have the unencrypted secret to perform the algorithm. So the principle of security in the system is that the machine that has those secrets should be kept in a secure location behind a firewall with the only port that should be accessible to support for performing authentication. When an authentication is done, the token of a token code submitted by the user is sent into the server over that TCP connection and the server sends back a yes or 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's 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, your security room, and there's a security server with no access to the encrypted routes. And we ask you when you buy the seeds 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 rather than using PGP. And they're kept in this situation, they're kept on a server that is not connected to the internet. Okay, thanks a lot.