Introduction
Today, security becomes more and more important. Very secure encryption and
authentication algorithms are designed (e.g. AES, SHA). But the best algorithms
are useless, if crackers bypass these systems by simply exploiting simple
security bugs of operating systems...
As you probably are thinking already, I am talking about the Windows Edit
controls. Most "normal" Windows programs use Edit controls, to get passwords
from the user. Normally you see stars (*) when you type something into an edit
box, that has the password flag. Unfortunately, these edit controls are not
secure. There are various methods for malicious programs and crackers to get the
password.
The first method is to simply remove the password flag. Windows doesn't do
anything against programs manipulating the window styles of other processes.
Just remove the ES_PASSWORD flag of an Edit box and zosh! You see
the entered text.
Another method is to read out the text of the Edit box. Use the Windows API
function GetWindowText on the Edit control and you get the text,
even if you are not the owner of the control (i.e. another process), and even
stars are displayed.
Therefor I created and present you now a control, which is very user-friendly
(Secure Edit controls look like normal Edit controls), and which is immune to
these spy tools, i.e. the methods above don't work at Secure Edit controls.
Features of the Secure Edit control
These are the features of the CSecureEdit class:
- Spies cannot read out the text of Secure Edit controls
- Removing the
ES_PASSWORD style doesn't affect Secure Edits
- Secure Edits look like normal Windows Edits
- User can insert a character anywhere (i.e. use cursor keys)
- User can delete one or more characters
- User can paste text into Secure Edit controls
- User cannot copy text out of Secure Edits
- Easy to implement for MFC developers
Technical background
So you want to know how Secure Edit controls work? Well, here we go.
Secure Edit controls have separate buffers for the real and the displayed
text. The displayed text is just the password character multiplicated with the
length of the real text.
Every time the user presses a key, the display buffer contains a non-password
character. Now it's time to replace this character with a password character and
update the internal real text buffer.
Secure Edit controls are derived from CEdits. They intercept the
EN_UPDATE message sent to edit controls, every time the content of
the control changes. The message is sent after Windows has updated its
contents, but not displayed it already.
The CSecureEdit class now looks what has happened. Has the user
inserted a character? Has he deleted one or more characters with Del or Bkspc?
Has he pasted some text into the control? First the class computes the length
difference of the old text and the new one. If this difference is lower than 0,
the user has deleted something.
In this case, we have to look where the cursor is. Now we can cut out the
deleted text from the internal buffer, based on the cursor position and
difference information. Now it gets tricky. What if the user has selected some
characters, lets say 4, and pressed a key? The difference is 3, 4 characters
have been deleted and one entered. In this case we first delete the 4 old
characters and let the character insertion routine run on the text.
In the other case (difference greater or equal zero), the user has inserted
text or replaced a character (range?) with another character (multiple?
clipboard?). Inserting is relatively easy. We just look at the display buffer
and search for non-password characters. These characters are new. The only thing
to do now is to compare the display buffer with the internal real text buffer
and insert the new characters of the display buffer to the internal buffer.
Finally we have to update the display buffer, i.e. replace all non-password
characters with password-characters.
Using Secure Edit Control
Implementing CSecureEdit is as easy as implementing other
customized controls, like "flat" controls or colorized controls.
Just follow these 4 steps to include Secure Edit Controls into your
project:
- Add the files SecureEdit.cpp and SecureEdit.h to your project.
- In the Visual Resource Editor of Visual Studio, create a normal edit
control.
- Right-click on the edit control and select Class Wizard.
- Create a new member variable for the control of type
CSecureEdit
That's it! You don't have to call any initialization or configuration
function.
To read the real text of the control, read out the public
CString member variable m_strRealText of the
CSecureEdit class. You don't have to call UpdateData
before the read, the control updates its text every time the user changes
something.
To set the text of a Secure Edit control, use its member function
SetRealText.
Some notes on the control
In contrast to normal edit controls, you cannot copy the password entered to
a secure edit control to the clipboard. But you can paste text into the
control. In my opinion this is the most reasonable solution. Paste something in
is allowed, copy something out is forbidden.
You can define the password character freely. But the character mustn't be
entered by the user. Currently the password character is such a special X. This
isn't the normal X, it's one of the higher ASCII characters which normally isn't
entered by the user (he would have to use an ALT-XX key combination to insert
it...). Therefor you shouldn't use the standard star (*) or other standard
characters like ! ? - _ $ or such...
Now go, download one or more of these spies, and use them on Secure Edit
controls. You'll see that the spies cannot reveal the passwords entered to a
Secure Edit control.
PwdSpy: http://www.codeguru.com/samples/pwdspy.html
Super Password Spy++: http://www.codeguru.com/ieprogram/SPwdSpy.html
History
-
29 May 2003 - v1.2 - The CSecureEdit class now supports
Unicode, thanks to Steven Spencer for support
-
18 May 2003 - v1.1 - Fixed a bug in the SetRealText
function
-
17 May 2003 - v1.0 - First official release
Well, thats it. Now go and be the first to release an application with
password edits resistant to window spies :-).
| You must Sign In to use this message board. |
|
|
 |
|
|
You realize that all that an attacker has to do is to set a hook in the process and then subclass your edit control. If you sublcass after him, he can intercept the SetWindowLong API and make sure his subclass is on top. Then he can trap the EN_UPDATE message just like you do and get at the password.
Also any key-sniffer (using either a low-level keyboard hook or simply get the GetAsyncKeyState API) can simply sniff out all passwords being typed. So any such user-mode solution to prevent password sniffing is futile. Unless your process runs in a desktop where other processes CANNOT set hooks into it, this is meaningless.
|
| Sign In·View Thread·PermaLink | 2.00/5 |
|
|
|
|
|
|
IMO, the main reason for such workarounds is to fight with grabbing of saved password.
You're right, password could be sniffed as they typed. But bigger security violation is to let someone to get the password that you have typed and saved some time ago.
So, to keep saved passwords in safety we shouldn't send full password-string to the control, but only a flag that we have a saved password. According to that flag, the control displays asterisks. But users should have no possibility to edit the saved password - on any his action the control should empty itself as if these characters were selected.
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Dear Reichl ,
Thanks for your Article .I don't have any problem with your "Secure Edit Control" .I just want to ask a question .
Recently i have Downloaded two Password Reavealer from following Addresses
http://www.codeguru.com/code/legacy/ieprogram/SPwdSpyDemo_Exe.zip
And
http://www.elcomsoft.com/ ----> (Commercial one)
But none of them can Reveal the "Change User Password" section in Control Panel Applet in windows XP.Also i tried them for Reaveling password from YahooMessaenger Login Page. The problem is that these programs has a magnifying glass for scanning Pasword Fields But this Magnifying glass can't Capture those area at all.I want to know what is wrong with these applications ?
Thanks in advance.
Regards.
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Microsoft has become aware of the problems with password edit controls and has implemented a special one for their login dialogs in Windows XP. This control also offers some protection against password spy utilities (a control like my Secure Edit Control). Unfortunately they only implemented the new secure control for the login dialog and don't make it a common control (i.e. you cannot use it in your application).
For YahooMessenger I don't know. Password controls in an Internet Explorer browser window are something special and you can't spy them with "normal" password spy tools. The first tool you listed should be able to spy it, if it's not possible maybe Yahoo implemented some protection against such attacks.
Best regards
Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? 
(doesn't work on NT)
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
 | Why? 
Reinout Hillmann | 8:13 29 May '03 |
|
|
The whole reason for the password edit control from Microsoft is to prevent over-the-shoulder snoopers from reading your password when you type it in. It does not prevent other applications from reading it since any clever application can read it from RAM. If the program has the rights to interact with your desktop (by sending messages) then it can do anything you can do anyway.
No offense meant, but calling this version of the Edit Control "secure" is misleading since the password is visible in plain text in a memory dump anyway. "More secure", yes but definitely not "secure".
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
BTW even if the API is secure you still can read a keystrokes ie intercepting keyboard messages. and the only way to secure that aspect is to randomly encrypt each keystroke. But such approach will render whole OS useless
|
| Sign In·View Thread·PermaLink | 2.00/5 |
|
|
|
|
|
|
It raises the level what a tool has to do. (And even though every lock can be picked, people still lock their front doors)
Further, the structure allows to store only a hash, or an encrypted password in memory. We don't need full-fledged cryptography to thwart "scan for text in a mem dump" attacks.
Flirt harder, I'm a Coder
mlog || Agile Programming | doxygen
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
I thought I read somewhere that the issue of being able to use GetWindowText(), ... on the password edit controls was fixed by MS? I don't have time to try it today, so I thought I would ask if anyone knows.
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
I remember that Microsoft has created some special password controls (I think it was in the login dialog of XP), but these aren't standard edit controls with the password flag. Standard edit controls with password flag set can be spied on all Windows systems as far as I know.
The authors of the password revealers I mentioned in my article claim that their tools work on Windows 95, 98, ME, NT, 2000 and XP. So Microsoft hasn't fixed this bug yet.
-Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
When I use unicode it seems to keep closing the app down and returning to the 'SetWindowsText' at line 109 in the Update function, apart from that it is very useful.
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Hello,
Thanks for your feedback! CSecureEdit now fully supports Unicode builds.
-Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Good. I have read your code already. Well, I see, you saved the real text inside the Edit class, and show a ***** string with the same length in the GUI. and sync these 2 string. But there is still a hole in your program, I could intercept the first WM_SETWINDOWTEXT, which is accompanied the real string
I hope you could extend the control without using MFC to make it more universal.
|
| Sign In·View Thread·PermaLink | 2.00/5 |
|
|
|
|
|
|
Hello,
thanks for your feedback! I've fixed the bug (new version uploaded already). The first WM_SETWINDOWTEXT doesn't reveal the password string any more. Try it
-Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
|
| Sign In·View Thread·PermaLink | 5.00/5 |
|
|
|
|
|
|
I see. Now the only way to crack is to trace the strcpy to crack which is not interesting very much
Cheers
|
| Sign In·View Thread·PermaLink | 2.00/5 |
|
|
|
|
|
|
The article looks pretty good! I haven't tried it out yet but based on your article I am sure it will work just fine.
Reading this I thought it would be fun to hook the password character up to a random character generator, so if someone was deviously looking over ones shoulder they would think they were typing the password in plaintext. And inevitably would try to attempt entry
Matt
BURN HIM! - David Wulff
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Nice idea, but normal users could get a bit confused if other characters appear than they type
-Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Dominik Reichl wrote:
Nice idea, but normal users could get a bit confused if other characters appear than they type
True, it wouldn't be good for the "average" user. But it would be fun for more advanced users.
Matt
BURN HIM! - David Wulff
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
A solution would be to keep the stars, but send these random characters whenever someone tries to crack the password by removing the ES_PASSWORD or by using the GetWindowText... 
Computers have enabled people to make more mistakes faster than almost any invention in history, with the possible exception of tequila and hand guns.
- Carl Gundlach
|
| Sign In·View Thread·PermaLink | 5.00/5 |
|
|
|
|
|
|
|
|
|
does this, and it's a real pain... 