When someone signs into their account, random pictures could be generated. That person would then look for their predetermined picture. Below that picture would be a randomly generated pass code. That pass code would then be a one time use code used to login to their account.
Pictures could be pulled from a public pool of uploaded pictures.
1 Like
I just spent some hours also contemplating anti-keylogging measures.
I keep getting stopped by the maidsafe architecture itself. There is no information about you available, until you decrypt it by providing your login details. This means that no secondary passwords, onetime pads, or in this case, pictures, can be used, because the launcher doesnāt know anything about anything, until a successful login occurs. Prior to login, there is just no information at all thatās available.
Unless you store some auxiliary data in a local file, that resides on your computer, but not on the maidsafe network, I think youāre stopped. The perfect is the enemy of the good, so perhaps some sort of local file that contained secondary passwords, onetime pads, or favorite pictures, could be used. It would have to be optional, so you could still access the maidsafe network if that file was destroyed. Not using that local data would remove keylogging protection, which is where we are now anyway.
At the very least, I hope that the launcher will accept arguments for login details.
maidsafe --user=user_name --password=your_password
Then I can create batch files that live on USB drives, phones, truecrypt drives, etc., so I donāt have to actually type anything. All a monitoring program would know is that I ran some script from an external drive.
3 Likes
The users picture could be pulled and mixed with random pictures during the self authentication process.
As an additional authentication process after the original self-authentication process.
The users picture could be pulled from where exactly, before authentication? Thatās what I keep running into. There is no safe place to store anything, prior to successful authentication.
1 Like
This could be optional as well. Some people are not as paranoid as others.
See above comment.
Even if the standard Launcher doesnāt accept command line parameters, it will be open source and trivial for someone to add this!
And what about RSA TOKENās?
Thereāre a lot in ebay:
I believe RSA tokens canāt work, because, again, there is no central server, and there is no datastore for you to access, prior to the actual successful login. How would the launcher know you typed in the right code? Where would it go to check?
The users picture could be acquired from the users login id which is acquired from the users keyword.
similar to how the password is authenticated.
Tom, I just checked and there will be a type of share that is accessible on SAFE prior to authentication, so this looks feasible. I guess the issue is then who controls it, but an app could create the share for the user, save the images etc., and public share it read only. That should work I think.
When you make a webapp, all of the things you talk about would work great.
For maidsafe, there is never a time when some entity consults some database to confirm whether or not you typed in the correct password. Instead, the userid and the pin provide a pointer to an encrypted blob of data, which is sent to you. You then use your password to attempt to decrypt that blob locally. If you succeed in this decryption, because you did have the correct password, that locally decrypted blob provides further keys to access your actual data.
So, prior to you sending the userid and pin and decrypting the returned blob of data with your password, you do not have access to any additional data that is special and private about your account other than userid, pin, and password. I am failing to understand where you have the opportunity to implement your temporary/supplementary passcode.
All of this could be handled locally, with a local program that served up your maidsafe login information when you jumped through the appropriate hoops, whatever those hoops happen to be. This moves the risk away from keyboard logging, but towards other attacks, perhaps.
Thatās interesting, but Iām still unconvinced. How does something thatās public for all to read, help me to authenticate safely?
You do have access to the network without being logged in - I just checked this. This is what allows anyone to access public shares even without an account. So this means there is a place where a library of files could be accessed, and known to be uncorruptable, because the share is owned by the user themselves (though visible to everyone).
So, this would work as follows - it has to be set up at account creation time though:
- account creator accesses a public share containing a library of images
- user provides required username
- app presents a selection of the images to the user who chooses N images using the mouse
- the app uses these N images to create a password string and a PIN
- app creates the account, creates a folder to hold the images in its app area and copies them to it from another public share, makes this public / read only. This ensures there is a library of images, including the ones selected and which recreate the password (and optionally the pin)
- user logs out.
Login:
- user starts launcher
- enters username and PIN
- launcher presents image sequences and user selects
- launcher recreates the password and PIN and authenticates with the network
Does that work?
I have thought about this some too ā Seems to me that you could do a bike -lock scroll wheel kinda thing ā If it was randomly set at load it would take random keystrokes to get the combination right ā But then you open yourself up to an even more pervasive problem of camera monitoringā¦ These days everyone has a camera on their hip or in their hand ā fewer people have keyloggersā¦
You could have them scroll slowly then press random keys for ignore and a particular key for accept ā and this would lessen the surveillance possibilities, but not eliminate themā¦
I am sure there is a slick and easy interface that would do the trick somebody just needs to invent it. If the interface it too cumbersome it will scare users away.
So, what youāre doing is not adding a supplementary password. Instead, youāre building the main password from a set of predefined legos.
So my password basically becomes āDuckPictureā āLionPictureā āCarPictureā āMountainPictureā āPandaPictureā
Is this correct? This seems to have a lot less entropy, and so would be a lot easier for me to supply your username, get a list of all your pictures, and try all permutations. I can also submit your username multiple times, and keep track of which pictures get served to me over and over again. āHmmm, Iāve only seen āJeepPictureā once, but I see āDuckPictureā, āLionPictureā and āPandaPictureā every time. I know those are part of his password, I donāt know what order. Oh, I see that āMountainPictureā and āCarPictureā are also shown to me every time. OK, Iāll just try every permutation of those 5 pictures, and Iām in businessā.
I guess you could make sure there were at least 15 pictures that were always returned every time, even if only a few of those were actually used. Now I have to try all permutations of 15 pictures. This begins to have reasonable entropy, I suppose.
I donāt see much use in working around keyloggers only to enable camera loggers ā Ideally we need something that requires both keyboard and camera feeds synchronized to hackā¦ If 1 channel surveillance is adequate, it will be used. 2 channels is a lot harderā¦ Particularly if the patterns are not very meaningful.
1 Like