views:

166

answers:

4

I've seen some password revealing software. Most of them has a shooting pointer like pointer and you can just point the password text box and the software is revealing the password.

But still the protected software and the revealer software are not interconnected. They are separate processes running on the same host.

My queries are,

  1. How does a one process access the other software's information?
  2. What are the limitations of it?
  3. What are the practices that I can use for prevent this?

Edit : Yes, Keeping a password with dummy data is the mostly used solution for this. But still the same theory can be applied to some other case right? As an example an external program can read your emails, A spy program can record your activities etc. And even we can implement some cool features like drag and drop support to IE to Mozilla :)

So in this case the most effective solution would be a "Blocking" mechanism. Is there anyway to do this? (Avoid accessing the process's resources???)

+2  A: 

Probably by finding the control and sending a message to the textbox that changes the 'password' character to blank (i.e. it will reeval).

So:

  1. By sending windows messages to them

  2. I can't recall, but I'm pretty sure you just need the window handle.

  3. Don't display the password in a password field at all. Just hold it somewhere in memory, and only show it if the user specifically asks for it.

Noon Silk
One of the pitfalls of Windows windowing. you can snoop and modify "windows" (read: controls of any sort) from any process.
Nick Bedford
+2  A: 

As silky said it's just a matter of sending windows messages, there is a very simple source that reveals all password fields at once. A simple countermeasure would be a password field that holds dummy characters instead of the real password. You can capture what is being typed, store it in a variable and replace it with the dummy character in your password field.

Diadistis
thanks for the storing it in a variable tip :)
hab
A: 

IIRC this "weakness" had been eliminated since about Windows XP SP2? In any case, i'm pretty sure the standard Windows textbox control that is used for passwords got an upgrade so that you couldn't just use tools like Spy++ to peek at the actual text that was being masked.

slugster
A: 

The way passwords work:
When a password is set the password is converted to a hash value using a hash function, and it is that hash value that is stored. The password is never stored. When a user logs in the password is hashed and compared to the stored hash value. If the two hashes match then the user submitted the correct password.

In order to reveal a password the stored hash value has to be compared to something with a known hash value or, in the case of a broken hash function, the hash value can be guessed into the submitted value. The later of these possibilities is the method used by Cisco password crackers, if you can get into the box, because Cisco uses a notoriously weak hash function. In the case of later Windows OSes the hash function used is NTLM, which is very strong. In this case you must compare the stored hash values to known hash values. This method is called a rainbow table. A typical alpha-numeric and 7-bit ASCII special character 14 character password has a rainbow table that is 64gb large. This is why longer passwords are vastly superior since it will take a few minutes to compare a hash value against billions of other values.