Observations from Key-logged Passwords

Published: 2014-05-03. Last Updated: 2014-05-03 16:23:04 UTC
by Kevin Liston (Version: 2)
8 comment(s)

I recently had the opportunity to look at a sample of key-logged passwords collected from compromised machine over a period of 4 years.  I wanted to share some of the takeaways, since I'm not comfortable sharing too many of the details.

From a collection of website credentials stolen by key-logger software I observed three common, trivially-predictable patterns.  The first was use of the term "password" slightly modified.  for example, Pa55w0rd, or PaSsW0rd, etc., etc.  The second was the use of a name followed by a 1.  For example, elizabeth1.  The surprise pattern, and the most common in the sample I got to look at involved the name of the site with 123 tacked on the end.  For example, isc123.

From a collection of remote-access passwords (shell, RPD, etc.) the usual suspects where admin/administrator (in various languages administrador, administrateur,) various permutations of "password," and the varying lengths of sequential digits (e.g. 1234, like your suitcase.)

In these samples, the source was a plain-text exposure, so it really didn't matter how complex or secure the passwords, since they were captured in the clear.  However, this gives us insight into how much effort is required to extract passwords when hashed credentials are exposed.  This also explains why brute-forcing remote access credentials is still profitable.

  • As a user, you should avoid using these quick, throwaway passwords.
  • As a website owner, you should not allow passwords ending in 1 or 123, that's a pretty simple filter to implement.
  • As a network owner, you should be brute forcing your own access credentials using a short hit-list.
  • As an ISC Handler, you should practice what you preach.
Keywords:
8 comment(s)

Comments

You are a prayer of a really dumb password voodooism. Look at isc.sans.org: Why do I need an account and a password for this site? To write a comment to your statement?

What is the worst, which can happen to me, if someone hacks my isc password? He can write a comment, signed - not with my name - but with one the the mail accounts I use. Scary? Nope!

So tell me: Why do I need an account just for writing a comment on this site?

Oh, Hey, it's Anti-Robot!

So because you fear spam, I shall use a password with "8 characters or longer with at least one uppercase letter, lowercase letter and numeric digit"?

Do you really think, that I will remember this password tomorrow? A password for a service without any really meaning for me? No, I will forget it faster than light! So I have two choices: Either I remember one real complex password and bind this to each and every service in the web I use.

Good Idea? Hell no, and you know why!

Alternative: I use a password safe. This password safe must reside somewhere in the cloud. Is it a good idea, to put access to all my secrets into the cloud? I don't think so.

Currently I have a case of an old guy, who believed in the words of prayers like you. His notebook was stolen, and since he choosed different complex passwords for different services, he trusted his browsers 'remember password-function'. But he didn't lock this function. He has a paper copy of all his passwords at home, but currently he is visiting his daughter several hundred miles away.

Now the thief of his notebook has access to any of his accounts - and that old guy has no chance to stop him, because he can't remember any of his complex passwords.


So the first rule should be: Never ask for a password, if your service don't really require an authentication. Grab your own nose and remove the password-border from the isc comment function.

Second rule: A password should never be more complex, than the service you offer is worthy. The ability to add a comment to your article is never, never as worthy as a password "with 8 characters, at least one blablablaa" is complex.

Third rule: If you urge people, to choose a complex password, very most people will find a way, to avoid this complexity. In effect, you are weakening password security much more, than simple passwords ever could! So if your service is worth enough, to demand for complex passwords than there are much better ways of authentication than this shitty medieval method of authentication!

And since I will forget my password for isc.sans.org otherwise, I will document it here: pustekuchenA7
Until recently, we did allow any password ("A" was perfectly fine) with the reasoning that we just let the user decide how much they think the account is worth. However, this was flagged in an audit of the site and we decided to change this to a more standard policy (min 8 characters, mixed case, one number....).

Realistically, you should use a "password safe" application of some sort anyway. Browsers even start ignoring the "autocomplete=off" setting to make it easier to use password safe features in browsers. The only good password is one you can't remember.

(BTW: comments by new users of this side are held for approval. There should have been a note when you submitted your post)
[quote=comment#30743]
Alternative: I use a password safe. This password safe must reside somewhere in the cloud. Is it a good idea, to put access to all my secrets into the cloud? I don't think so.
[/quote]

This isn't necessarily true. See for example keepass/keepassx - no cloud required.


[quote=comment#30743]
So if your service is worth enough, to demand for complex passwords than there are much better ways of authentication than this shitty medieval method of authentication!
[/quote]

Ignoring your trolling, you make some decent points. But it seems to me that password-less logins are still a work-in-progress, and that only recently have frameworks been doing a good job at making logins easier (e.g. via centralized authentication or two-factor).
I use a password safe as well. I use 1password, and a synced folder, so it is in the cloud (but encrypted - And I have 2-factor on the cloud service for the times when they elect to validate passwords - DropBox). I use cloud such that I can have the safe available on Windows/Mac/iPhone/iPad.
Well if Steve Gibson at GRC ever gets it finished, then I think his SQRL is perfect for this sort of situation.
There is another option you failed to mention though many here would tend to agree it should be discouraged.

I will go ahead and admit, even though I have had it drilled into my head many times that you should NEVER use the same password on multiple sites, I do have a few passwords that I tend to use a lot on many sites where I really could care less if someone with malicious intent had access to.

As "Anonymous" said, so what if someone else logs on as me and posts a comment on a website (especially one that has no service fees or penalties to prevent me from creating another account).

Aside from the troll-ish nature of that comment, there were a lot of good points. I have to agree that passwords for the sake of passwords (or just to keep some manager happy) is generally a bad idea if the service doesn't warrant security.
Just a side note:

What is the point of the scroll bars on the right of these comments when the table expands to fit the text?
(This seems to only affect IE and not FireFox but I haven't tested any other browsers.)
There is another reason for requiring the user to log in before they can comment: it can limit abuse by automated spamming. With no login before posting, the forum could be flooded with spam messages by bots. (I have seen this happen and it can destroy a forum!) The login forces potential spammers to create an account which can then be deactivated/deleted if they abuse the terms and conditions.

Diary Archives