aspose file tools*
The moose likes Java in General and the fly likes protect application from keystroke recorder apps which can record passwords/public key? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "protect application from keystroke recorder apps which can record passwords/public key?" Watch "protect application from keystroke recorder apps which can record passwords/public key?" New topic
Author

protect application from keystroke recorder apps which can record passwords/public key?

naved momin
Ranch Hand

Joined: Jul 03, 2011
Posts: 692

Once our professor cross-questioned my friend that , can your encryption-decryption software protect from keystroke recorder softwares ?
then my friend told me about this because that software is made by me only using *.crypto package of java , I can't tell any solution for that , can any one has any solution for that problem

to cut-short : keystroke recorder records every keystroke even when , my user enter a public key for encryption-decryption process , so for that I am searching a solution for this problem


The Only way to learn is ...........do!
Visit my blog http://inaved-momin.blogspot.com/
Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

The general solution to this problem is not to defeat the keystroke reader, but to introduce a second factor of authentication.
For example, I have a device called a Yubikey that generates one-time passwords and plugs into my USB slot. If an attacker installed a keystroke recorder ( keylogger) on my system and captured my password, they would still need to be in possession of this Yubikey to get into my applications.

The perfect world for many security experts is to have three-factor authentication that consists of something you know (the password), something you have ( the yubikey) and something you ARE (fingerprint, voice identification, eyeball scan, etc.). Obviously, this would be overkill and too expensive for most needs.

If you are just looking for a software based solution that you could implement in Java, there have been many tricks proposed (onscreen keyboards and other appliances that scramble the input and make it harder for a keylogger to capture what you enter) but all of these have been defeated. Not easily defeated, of course. I couldn't defeat them, but they have been defeated.
naved momin
Ranch Hand

Joined: Jul 03, 2011
Posts: 692

Tim McGuire wrote:

If you are just looking for a software based solution that you could implement in Java, there have been many tricks proposed (onscreen keyboards and other appliances that scramble the input and make it harder for a keylogger to capture what you enter) but all of these have been defeated. Not easily defeated, of course. I couldn't defeat them, but they have been defeated.

so you saying that , the key logger only records the keystroke from keyboards, so if we would make a GUI which will have a numbers from 0-9 and alphabets from (a-z|A-Z) on buttons and user will select the password from this buttons through mouse clicks and not by keystrokes , so in this way we can defeat the key logger right ?
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14103
    
  16

Yes, that will defeat a simple key logger, but as Tim said, then an attacker can make another program that records where your mouse pointer moves and where you click, so it can find out that way what you're entering with the mouse.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
naved momin
Ranch Hand

Joined: Jul 03, 2011
Posts: 692

Jesper de Jong wrote:Yes, that will defeat a simple key logger, but as Tim said, then an attacker can make another program that records where your mouse pointer moves and where you click, so it can find out that way what you're entering with the mouse.

first i didn't understand how an attacker can figured out on which button user is clicking for that i guess attacker need to record the entire frame like an automation test tool

so does any one has any idea to defeat this kinds of attack ?
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19670
    
  18

As implied by Tim, you would need something that can generate extra authentication tokens for the users.

Many banks in my country use some form of card reader that, when the bank card is inserted, generates a key that is valid for only a few minutes at most. World of Warcraft has the same technique, either as a little code-generating device or as a mobile application. These too generate tokens that are valid for a short time. If you wait too long you have to generate a new token.

That last part is very important. A token can still be intercepted and used until it is invalidated. The shorter the invalidation time, the better.
Also, the token generation algorithm should be complex enough to not be easily found out. It's no use to protect your application with generated tokens if malign people can generate their own valid tokens.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3610
    
  60

naved momin wrote:first i didn't understand how an attacker can figured out on which button user is clicking for that i guess attacker need to record the entire frame like an automation test tool

so does any one has any idea to defeat this kinds of attack ?

No, a Java application generally cannot prevent another application running on the same computer from recording the content of the screen.

Some video players use special graphic card acceleration which puts the video being played directly into a region on the screen, without writing the video to the graphic card memory. Such content is generally not recorded in a screen shot. I'm not sure firstly whether such capability this is available to Java application, and secondly whether such contents cannot be spied on using some more sophisticated means, probably it could.

The above is just a theoretical exercise. Even if feasible, it would seem a great overkill to me. More common solutions have already been mentioned here.
naved momin
Ranch Hand

Joined: Jul 03, 2011
Posts: 692

Rob Spoor wrote:As implied by Tim, you would need something that can generate extra authentication tokens for the users.

Many banks in my country use some form of card reader that, when the bank card is inserted, generates a key that is valid for only a few minutes at most. World of Warcraft has the same technique, either as a little code-generating device or as a mobile application. These too generate tokens that are valid for a short time. If you wait too long you have to generate a new token.

That last part is very important. A token can still be intercepted and used until it is invalidated. The shorter the invalidation time, the better.
Also, the token generation algorithm should be complex enough to not be easily found out. It's no use to protect your application with generated tokens if malign people can generate their own valid tokens.

Sorry rob, can't the attacker steal the card from the card holder and make wrong use of it. because I assume it relies on single factor of authentication i.e.(something you have) i.e. card
and the key get generated which is valid for small amount of minutes like a Session in web application.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

naved momin wrote:Sorry rob, can't the attacker steal the card from the card holder and make wrong use of it. because I assume it relies on single factor of authentication i.e.(something you have) i.e. card and the key get generated which is valid for small amount of minutes like a Session in web application.


Yes, if someone steals the hardware token device, then clearly they can use it. If prior to getting the device, they had a keystroke recorder on the computer (usually at a level below anything Java, as its in the inner guts of the operating system) then the bad guy, Mallet, can record your userid and password and enter the value from the hardware token and get in.

This is a previously known to be impossible problem.

Similarly, most serious security folks consider hard disk encryption to be only useful if you keep the disk away from the bad guy. If Mallet can take the disk to his secret headquarters and have the NSA, ISI, MI-5, Mosad, etc folks spend months breaking it, they will.
naved momin
Ranch Hand

Joined: Jul 03, 2011
Posts: 692

Pat Farrell wrote:
naved momin wrote:Sorry rob, can't the attacker steal the card from the card holder and make wrong use of it. because I assume it relies on single factor of authentication i.e.(something you have) i.e. card and the key get generated which is valid for small amount of minutes like a Session in web application.


Yes, if someone steals the hardware token device, then clearly they can use it. If prior to getting the device, they had a keystroke recorder on the computer (usually at a level below anything Java, as its in the inner guts of the operating system) then the bad guy, Mallet, can record your userid and password and enter the value from the hardware token and get in.

This is a previously known to be impossible problem.

Similarly, most serious security folks consider hard disk encryption to be only useful if you keep the disk away from the bad guy. If Mallet can take the disk to his secret headquarters and have the NSA, ISI, MI-5, Mosad, etc folks spend months breaking it, they will.

Just tell me whether this is good, bad, ugly way for 2 way authentication

what I was thinking of making is a virtual keyboard on screen from where user will enter the password/key though mouse clicks , once he has done that he will click on some button say "encryp button"
then a dialog box will prompt him to insert a token , now token will be based on the principle (something you have) so suppose it is pen drive because most people in the world has pen drive and it is cheap
also for buying so user will enter his pen drive and then my code will perform a look-up to check the pen drive name , if the pen drive's name will be the name I was expecting than I can allow the person for further processing else throw him out ....
how many of you think , that this is a good way of doing 2 way authentication based on something you know (key/password) and something you have (pen drive/cellphones etc.) ?

so in this way if attacker is not physically present next to the machine , he will have no idea of knowing how the person gets authenticated .
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1760
    
    7

naved momin wrote:
Sorry rob, can't the attacker steal the card from the card holder and make wrong use of it. because I assume it relies on single factor of authentication i.e.(something you have) i.e. card
and the key get generated which is valid for small amount of minutes like a Session in web application.


Well, it's not quite that simple. The way my bank handles security covers two of the aspects mentioned.
You need a card reader, a bank card and a four digit PIN number to generate a temporary code, using the card reader. To generate a temporary code you insert your card into the reader, select the mode (read-only) for which to generate a temporary code and enter the PIN code, for which you have a maximum of three attempts to get it right. The online banking software requires you to enter your account number, the card ID and this generated code for authentication and grants you read-only authorization. If you want to acutally transfer money, you'll be required to generate another key using a different mode off the card reader, which requires you to enter your PIN code and additionally a code generated by the banking software into the card reader. You enter the resulting generated code back into the banking software and if everything checks out your money transfer request will be approved.

Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

naved momin wrote:Just tell me whether this is good, bad, ugly way for 2 way authentication


Who is your threat? Your 8 year old sister? If so, it might be almost good.

If you are worried about a professional, you need to back up a lot and rethink it. I see nothing in your approach that deals with trivial replay attacks.

Most keystroke recorder systems are down in the OS driver level, or below.

The useful hardware tokens (from RSA, Verisign, etc.) generate and display a number that changes frequently, often more than once a minute. It is the changing number that makes it useful.
naved momin
Ranch Hand

Joined: Jul 03, 2011
Posts: 692

Pat Farrell wrote:
naved momin wrote:Just tell me whether this is good, bad, ugly way for 2 way authentication


Who is your threat? Your 8 year old sister? If so, it might be almost good.

If you are worried about a professional, you need to back up a lot and rethink it. I see nothing in your approach that deals with trivial replay attacks.

Most keystroke recorder systems are down in the OS driver level, or below.

The useful hardware tokens (from RSA, Verisign, etc.) generate and display a number that changes frequently, often more than once a minute. It is the changing number that makes it useful.

thanks pat..but I have to figured out a thing on principle (something you have) which should be cheap enough to get peoples attention , because this RSA and what you have mentioned all are pretty costly.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

naved momin wrote:but I have to figured out a thing on principle (something you have) which should be cheap enough to get peoples attention , because this RSA and what you have mentioned all are pretty costly.


Again, I ask: who are you protecting the system from? Your little sister? or a 18 year old guy who hacks because he has no life? or a professional industrial spy?
You will get different answers depending on what your threat model is.

A critical thing for effective security is prevention of replay attacks. So far, I see nothing in your proposed design that addresses this critical issue. Do you understand what the term means?
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

naved momin wrote:
what I was thinking of making is a virtual keyboard on screen from where user will enter the password/key though mouse clicks ,


Probably not that hard to defeat this.

once he has done that he will click on some button say "encryp button"


Which does what, exactly?

then a dialog box will prompt him to insert a token , now token will be based on the principle (something you have) so suppose it is pen drive because most people in the world has pen drive and it is cheap
also for buying so user will enter his pen drive and then my code will perform a look-up to check the pen drive name , if the pen drive's name will be the name I was expecting than I can allow the person for further processing else throw him out ....


And how does your app know what name to look for? Where does that come from?

so in this way if attacker is not physically present next to the machine , he will have no idea of knowing how the person gets authenticated .


Since you're assuming he can inject a keystroke reader, you might as well assume he can inject a USB sniffer as well.
naved momin
Ranch Hand

Joined: Jul 03, 2011
Posts: 692

Pat Farrell wrote:
naved momin wrote:but I have to figured out a thing on principle (something you have) which should be cheap enough to get peoples attention , because this RSA and what you have mentioned all are pretty costly.


Again, I ask: who are you protecting the system from? Your little sister? or a 18 year old guy who hacks because he has no life? or a professional industrial spy?
You will get different answers depending on what your threat model is.

A critical thing for effective security is prevention of replay attacks. So far, I see nothing in your proposed design that addresses this critical issue. Do you understand what the term means?

No, I am not doing such a hard work for my little sister nor for a 18 year old hacker dude, I am doing this because if I propose this system or show it to some experience developer , first expression of that guy should be wow, So you can guess "professional developer" in your terminology therefore I am asking the opinion of you guys.
naved momin
Ranch Hand

Joined: Jul 03, 2011
Posts: 692

Pat Farrell wrote:

A critical thing for effective security is prevention of replay attacks. So far, I see nothing in your proposed design that addresses this critical issue. Do you understand what the term means?

but i guess replay attacks come into picture when we are coding web apps ? In desktop apps how you do reply attack please explain ? because in this attacker doesn't have any valid connection to the target machine .
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

naved momin wrote:In desktop apps how you do reply attack please explain ? because in this attacker doesn't have any valid connection to the target machine .


From the very beginning, your threat model has assumed the attacker has injected a keystroke sniffer. If he can do that, we must assume he can monitor all your machine's I/O.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

naved momin wrote:I am doing this because if I propose this system or show it to some experience developer , first expression of that guy should be wow, So you can guess "professional developer"


I don't mean to discourage you, just trying to inject a does of reality. If you're trying to wow a professional developer who, I assume, is knowledgeable about computer security, you're going to need to learn a lot more about the topic than you can get from a forum. I'm talking serious study. I wouldn't be surprised if the greatest threat to computer security, after social engineering, is people who don't really understand the topic coming up with something that sounds sufficiently complex to themselves and then claiming it's secure.

So by all means, continue designing and developing this. Just please make sure you actually understand what makes it secure, and where its weak points are.

Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

naved momin wrote:
Pat Farrell wrote:A critical thing for effective security is prevention of replay attacks.

but i guess replay attacks come into picture when we are coding web apps ? In desktop apps how you do reply attack please explain ? because in this attacker doesn't have any valid connection to the target machine .


You should google replay attacks.

Any system is subject to replay attacks. They are simple: record what the real users does. from login to logoff. Sometime when the user is gone, play back the login process, character by character. The system under attack will think that a real person is logging in, and now the Bad Guy(tm) is in.

The bad guy doesn't even have to do the replay on the same machine. They can transfer the recorded data to an external host, and replay it on their machine at a time and place of their choice.

Your basic assumptions, such as "attacker doesn't have any valid connection to the target machine" is simply not justified. If they can install a keystroke logger, they own the machine, and can do anything they want.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

naved momin wrote: I am doing this because if I propose this system or show it to some experience developer , first expression of that guy should be wow


The good news is that the average professional Java developer has no idea what security is, and can be made to saw "wow" fairly easily. This is too low a hurdle for anything serious.

Real security is a complex topic that requires understanding of a large number of topics. The most important is to fully understand humans, and social engineering. Then there are a lot of technical things to understand such as cryptography, internals of operating systems, internals of networks. There are many books on the topic going back 30 or 40 years. There are many websites covering parts of it.
 
Consider Paul's rocket mass heater.
 
subject: protect application from keystroke recorder apps which can record passwords/public key?