avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • December 12, 2018, 07:14 PM
  • Proudly celebrating 13 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: fSekrit & keylogging  (Read 5551 times)


  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 116
    • View Profile
    • Donate to Member
fSekrit & keylogging
« on: July 31, 2006, 09:37 PM »
Say you're travelling and using internet cafes to stay in touch, pay bills, top up your credit card, etc.
It seems to me that such cafes would be the likeliest places to be insecure and have such things as key loggers running.
Is there any way to overcome this security weakness either when using fSekrit or any other encryption software?
I have some personal details stored at an encrypted web mail provider. If I can't remember a password for an account I go there and check my mail, but that is probably a risk too as when I open the e-mail containing the info it's probably put in a temp file on the computer I'm using.
Any thoughts on security when travelling?


  • Moderator
  • Joined in 2005
  • *****
  • Posts: 9,134
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: fSekrit & keylogging
« Reply #1 on: August 01, 2006, 06:12 AM »
Definitely do NOT depend on the on-screen keyboard!

IMHO the way that works best is to type your passphrase out of sequence, using the mouse to reposition the caret. A password like "gromit99wallace32" might end up as a keystream of "tgrallce3mio99wa2". It *IS* annoying to do this though, especially because the password input field is masked...

And it's not foolproof, if the keylogger places some API breakpoints rather than just snooping raw keys, it can easily get the "pieced-together" final passphrase.

There's a couple of solutions that could be applied.

1) Kernel-mode driver code (could also solve the page-to-disk problems)
   Too much work and bother. Requires different drivers for 9x/NT/64bit. Not suitable for use on limited user accounts and usb flash drives.

2) Custom control for keyboard input.
   Requires *some* work and would add a bit of bloat, but is doable. Still requires the "shuffled" way of inputting data, but at least it would overcome the "breakpoint on GetDlgItemText" problem.

3) Some additional "visual clue".
   If you had to, say, pick three colors from a 16-color palette in addition to your passphrase, then a generic keylogger wouldn't give all the data necessary to open the file (unless it also logged client-relative mouse events, *sigh*). A targetted attack would still be possible, though.
- carpe noctem