Aren't passwords written in inputbox vulnerable through a stack trace ?

Question

Hello,
I am not a guru of the stack tracing, at all. I even don't know how to get some. Anyway, I am wondering if entering a password entered in an inputbox is safe. Can't it be retrieved by getting a stack trace ?
A password entered that way will be found in many places :

• Caption property of the TEdit
• Result of the function which creates the inputbox
• probably, a variable that stores the Result of the InputBox Command
• etc...

If the answer is "yes, it is a vulnerability", then my world collapses :p. What can be done to avoid that vulnerability hole ?

NOTE : The InputBox is an example but it can be with a "homebrewed" login prompt.
InputBox is a Delphi command but I haven't tagged the question with the Delphi tag because I suppose that the question concerns any language.

Thanks for reading

Answer 1

This is called the airtight hatchway problem, and stems (at least one of the sources) from a chapter in a book by Douglas Adams called The Hitchhikers Guide to the Galaxy. In it, our two protagonists are being carried by a large guard and dumped into a airlock, pending being evacuated into space. At some point, one of our protagonists says that he had a solution, but "it rather involved being on the other side of the airtight hatchway.".

Let me explain.

If you have a cracker that is able to execute code (or in other ways "be") on your own machine, you have already lost. There's a ton of things that the cracker can do at that point.

So your first line of defense should be to prevent bad-guys access to your machine, if you can handle that, security becomes much easier.

So no, this is not a vulnerability, it is the fundamental way your computer works.

In the simplest form, if someone is able to get hold of runtime live stack-traces of your program in motion, it probably means they have hooked up something that looks like a debugger to your program and is able to "debug" your program as it runs. A breakpoint could easily grab data from memory, process it, and then resume the program without the user ever knowing anything has happened, but in practice, there are far easier way to get hold of such information provided you can execute code on the system.

Now, having said that, in .NET and many other runtimes there is support for attempts to at least make it harder, by instead of storing the whole string, they intercept one and one keystroke into your input box, and encodes it together with the rest of the password, so that each character is not stored in plain-text.

However, the code that handles this becomes very cumbersome to work with, simply because any attempt to get the whole password in clear-text would make the whole exercise pointless, so unless you're able to pass such encoded passwords end-to-end around your system, this won't really help much.

In .NET, the class in question is System.SecureString.

However, again, if the bad-guy can execute code on your platform, what is there to stop him from intercepting the keystrokes and just combining them together to form your password?

Here's a couple of links with examples of similar questions:

• It rather involved being on the other side of this airtight hatchway: Dubious escalation
• It rather involved being on the other side of this airtight hatchway: If they can inject code, then they can run code
• It rather involved being on the other side of this airtight hatchway: Elevation to administrator

You can tell I'm a fan of Raymond Chen.