Secure Edit Control (MFC)



Click here for a larger image.

Environment: VC5/VC6/VC7, Win95/98/ME/NT/2000/XP

Introduction

Today, security becomes more and more important. Very secure encryption and authentication algorithms are designed (for example, AES and 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 (as in, another process), and even stars are displayed.

Therefore, I created and present to you now a control that is very user-friendly (Secure Edit controls look like normal Edit controls), and that is immune to these spy tools; in other words, 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 (for example, 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 at 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, let's 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 than or equal to 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; in other words, replace all non-password characters with password-characters.

Using Secure Edit Control

Implementing CSecureEdit is as easy as implementing other customized controls, such as "flat" controls or colorized controls.

Just follow these four 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 VC 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. Pasting something in is allowed, but copying 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...). Therefore, 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

Downloads

Download demo project - 70 Kb
Download source - 11 Kb


Comments

  • OOoopps

    Posted by Legacy on 06/06/2003 12:00am

    Originally posted by: 8ball

    When I use MSVC++ Spy on the the secure edit control and filter the message group down to 'Keyboard', I see every character typed.

    Reply
  • nmm... I am making an anti-anti-peeking program, hope it will work...

    Posted by Legacy on 06/04/2003 12:00am

    Originally posted by: Zhefu Zhang

    nice work anyway. and May I ask how many days it took between the submission and the post of yr article this time on CodeGuru?

    Reply
  • basic idea about hacking this... maybe not working

    Posted by Legacy on 06/04/2003 12:00am

    Originally posted by: Zhefu Zhang

    The edit save the real data in a CString member inside the Edit class.
    For I am not sure how MFC CString works inside,( unlike ATL type class, MFC CString code is unavailable) IF CString do not reallocate itself when shrinking like this: str = str.Left(str.GetLength() - 1), we have a chance. My first idea is to read its process space, make a snapshot of the whole process, and try to change the password (cut it one by one char), rescan the process space..
    Another possible thing to imagine is (when MFC CString use API string function instead of the CRT), hook all string WinAPI and catch the password. (when CRT used, oh, man, we have to use a debugger like SoftIce to do the dirty work...).
    In the end, this edit will make pwd peeking a pain task anyway.

    Reply
  • very good!but a little bug.

    Posted by Legacy on 06/03/2003 12:00am

    Originally posted by: violet

    In the file SecureEdit.h,there shoud be
    #define SE_PASSWORD_CHAR _T('?')
    right?

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • IBM Worklight is a mobile application development platform that lets you extend your business to mobile devices. It is designed to provide an open, comprehensive platform to build, run and manage HTML5, hybrid and native mobile apps.

  • Companies must routinely transfer files and share data to run their business, work with partners, and speed operations. However, many find the traditional approach to file transfer lacks necessary security, is too complex and difficult to manage, does not support the levels of automation needed, and breaks down when addressing the file transfer requirements of new areas like Big Data analytics and mobile applications. This QuinStreet SmartSelect discusses how the changing business environment is making the use …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds