Dual layer login to resist keyloggers

http://www.hacker10.com/computer-security/hardware-authentication-systems-swekey-yubikey/

What is a One-Time Password (OTP)?
A One-Time Password (OTP) is a password valid only for a single use and, once used,
cannot be used again for authentication. A Yubico OTP is unique
sequence of characters generated every time the YubiKey button is
touched. The Yubico OTP is comprised of a sequence of 32 Modhex
characters representing information encrypted with a 128 bit AES-128
key.

As I understand it, one-time passwords need server-side support. Which we don’t have in SAFE.

What I want is a USB device with a number of write-only 512 bits memory banks, to store private keys in them. Any data stream send to the device would be decrypted or signed by one of the keys, and then returned as output. That way the self-authentication process can be completely bypassed for regular usage of SAFE.

I would still store the revocation key on SAFE using the self-authentication protocol, in case I lose the USB device or if malware overwrote the encryption keys just to sabotage.

2 Likes

My understanding is that one of the following applies.

This would be done by the group sending out a challenge and waiting for crypto response like described in SQRL described on GRC’s website. There is a thread on it for website logons.

The Group would replace the server for the one time password. EG googles 2FA thingo.

We should develop one using a cheap linux computer, like the $9 CHIP that will be available early next year.

Hmm, I’m not sure this is impractical at all. I don’t have time to review this but what is needed is something on the server that can perform a calculation - let’s say you upload the one time pad to an SD item that can only be read by a closed group handling access to your self-encrypted data map.

So there’s your map which is normally retrieved using keyword+pin, and returned to you for decryption by your password.

Instead we have the map and a OTP SD item, each retrieved according to your keyword+pin. The closed group has access to the OTP (but can’t decrypt the datamap) which it uses to verify the OTP phrase you presented along with keyword+pin. If your OTP fails, it returns a garbage datamap, if it succeeds it updates the SD item (strikes off the OTP phrase you provided) and returns the correct datamap.

As I say, I don’t have time to review this but based on my limited understanding of OTP I think this might work. You’ll need an App to help you create and manage your OTP SD, and it will need the network to provide closed group concensus handling of this (because I

Inexpensive offline private key signing devices are a very good idea, and would work for lots of applications – They could work over bluetooth, visually (with camera) or with serial over USB or with NFC.

Probably a chicken and egg issue is all that his holding them back.

The Website or system can generate a nonce for the user to sign and return – that can be verified with the user’s public key - Done deal…

Thanx for the links. I have failed to find anything in the content linked that explains how these “keys” get around the interception problem. In memory/RAM everything must be decrypted before the authenticating information can be passed over to the target program. I think this is really important to understand on my part. Someone, please help me understand this. This could be the ultimate solution with proper SW support.

I wonder if this has been proposed before, but at least to make screen capture keylogging that much more difficult, we could implement animated numbers/letters on an on screen keyboard. They’d be scrambled and would only be legible if one were to see the animation. Like for instance a sea of blue with white balls floating in it. These balls would trace the outlines of letters/numbers in a way that would take advantage of persistence of vision. Even if you capture a picture every time you click, you’ll have no useful data. You would need to be capturing video at all times and then save the previous few seconds of footage each time. I don’t think it’d be completely logging-proof, but it’s at least one step ahead in the arms race of logging.

Does anyone have any improvements to this idea to make it even harder to log?
Or on the other hand some easy way of making this idea useless. :stuck_out_tongue_winking_eye:

"You would need to be capturing video at all times and then save the previous few seconds of footage each time."
There you invalidate your idea yourself.

Any “solution” you guys may have that is software based you are just moving the post, without solving it.
The only solution against loggers is out-of-band authentication, period.

Why are people insisting on useless effort?

1 Like

There is a video, and I can’t seem to find it. Some japanese is working on a solution that prevents keyloggers. It has multiple mouses icons on the screen, flying all over the place. You need find the actual mouse icon, and dial the number. But if you move faster than other mouses, it can be easily detected. So the solution is go with the flow with other mouse icons. The hackers would have hard time guesting.

Next scene, they came up with a much better solution. It has a wheel, with 10 chucks. Each chuck comes with a number. There are 6 mouse icons over the chuck button, and somehow you know the actual one but the others don’t. When you click a chuck, the other 5 chucks are clicked as well however, the 5 chucks are an illusion clicks.

But what stops the malware to log the x and y axis of the real interface? If it is identifiable by the user, it is identifiable by software.
As said before, it is a useless effort to try to find a solution on band.

So we need hardware encryption, and hardware out of band authentication?

That’ll be out of everybody’s league except for hardware designers.

As long as you own a cellphone, you can use it to authenticate out of band.
For specializefd tokens such as yubikeys it only requires plugging in a USB and pressing a button.

Do you really think that it is that hard to do that?

Help me out here piluso. I posed a question above in regard to interception. One time passwords are indeed a solid temporary solution, but a pre-programmed reusable password or key entity (picture, bio-metrics, etc) is susceptible to interception regardless to the device it originates from. Everything is decrypted in memory before authentication and any public key is easily captured by malware. Am I wrong in my understanding?

It seems that a couple of methods have been combined in your question.

One was that the USB device entered the password for the person saving them the requirement to remember it. That is definitely open for a keylogger to capture.

Another is the challenge-response exchange. This is where the USB device receives a challenge from the web site or server and the device

  • uses the public key of the web site to decode the challenge thus ensuring it is the correct web-site or server
  • then it encodes a response using its private key and sends that back to the site/server, thus the server verifies the device is valid using the publicly available public key given to the web site for this account
  • if a keylogger/memory-logger/malware intercepts the exchange, it will do it no good because no key has passed during the exchange, and all the exchange is encrypted whilst in the PC
  • the challenge is never the same so the malware cannot succeed by recording the exchange
  • the malware never gets access to the private key of either the website or device either since they are never contained in the exchange…

Now obviously the malware can still interfere with/record the session, but it cannot log into the persons account nor allow anyone else to.

2 Likes

Has this challenge based system already been deployed? If so, how are the challenges devised? Can’t the private key be taken from the device? If the challenges are never the same how can the system be sure that it is you? The challenge would have to be used to verify that a user has some intimate knowledge regarding something that the attacker cannot easily anticipate. From what pool of information does it gather this from and how does it then create an infinite number of combinations only you could solve? This could revolutionize authentication if done properly, but I’ve yet to find a working solution.

One idea I have (probably not original or even good) is to have a secondary read only device with a megabyte or less of volatile memory. When a service like SAFE is accessed by the user and the physical authentication key, SAFE encrypts a new one time password with the hardware keys’ public key. It then passes it to the hardware key for future use. To avoid malware interception of the decrypted password. The user must first remove the hardware key and place it into the secondary dedicated read only device for out of band decryption. As the secondary "Decryptor device" is read only it cannot be infected remotely. The hardware key can also be designed not to allow for a payload greater than n to be received so as to guarantee that the hardware key cannot be infected by coupling the encrypted password given by the SAFE client with it’s own malware. So lets say n is the maximum allowable payload. SAFE or any other authentication system would be designed to only create encrypted passwords that result in a payload the size of n. Basically filling all of the allowable space on the hardware key, leaving no room for malware attachments.

I envision the second device (the “Decryptor”) being a very small unit no more than twice the size of an average USB stick. In it would be a slow super low power ARM cpu, the absolute minimum necessary RAM necessary to decrypt the 256bit AES blob provided by SAFE. Again, it would be read only and thus insusceptible to software infection. It could be powered by a AAA battery.

Now to reiterate, the user opens the SAFE client. The user authenticates using the hardware key. SAFEnet at the network level creates a new one time password, encrypts it with the hardware keys’ public key. SAFE passes this new encrypted password to the hardware key. In order for the user to use the new one time PW, the hardware key must be removed from the computer and inserted into the “Decrypter device”. The decrypter then does the necessary calculations and decrypts the new password using the private key. It then passes the decrypted password to the hardware key to be used at a later time. It’s a lot simpler than it sounds.

If you’re wondering if the device could be used with multiple services each with their own credentials. Fearing that if the encrypted key/password must fill all the available space on the hardware key it cannot be used by anything else. I propose an on demand key loading ability wherein a service such as SAFE, Amazon, random bank etc, gives you the choice of sending the encrypted key it generates either directly to your hardware key device or allowing you to save it as a file on your system to be later loaded onto the hardware key. A user could have a folder full of encrypted keys for various services. These keys could be copied and scattered throughout their computing ecosystem (email, backup drive, cloud, etc). When ready, a user simply copies the relevant key into their hardware key, decrypts it with the “Decrypter”, then authenticates as normal.

Sorry for all the redundant information. I just wanted to be clear enough for those who require reiterative breakdown.

That awfully reminds me of “Hardware Workaround” component from my solution schematically displayed below! Great minds think alike!

They have been in many situations, like business, gov security agencies etc

There is another similar system being supported by GRC which David asked for us to look at and it can tailored as a login sequence for those wishing it. RFC Possibility SQRL And follow the links to GRC website and it will answer a lot of your questions. So rather than we take up forum space answering your questions which will be ever increasing as we answer the one already asked, just read the GRC site about this topic

1 Like

Thanx! Looking in to it.

1 Like

Sorry for digging this one up, but has there been some thought in how out of band or OTP passwords could be implemented ? Securing my data with a pw and pin seems very vulnerable to keyloggers/malware. If I ran a business with a gazillion bytes of private data, I wouldn’t want the password/pin combo for sale on a vague website without the ability to change either one of those. That means once it’s out there, it’s out there…

1 Like