gushi: (Default)

Let's face it. Tokens are just cool to geeks.

While early on, working for a pi firm in 1999, I used Cryptocards, I was hooked.

Here was one of those little things that gave you a challenge, and you had to put into your cryptocard, get an answer back, and type out the response. A correct response couldn't be used more than once. On top of everything, the cryptocard itself had a PIN when you turned it on. It was, in a word, pretty foolproof. There's always the option of "put a gun to my head and ask for the pin", but I think the things even have a "duress pin", which bricks the device.

Cryptocards aren't user-friendly, tho. It gets annoying.

The most popular maker of this stuff on the market is a little company called RSA. They have a product that they call "SecuriD". These are still considered "two-factor" authentication (something you have, plus something you know), even though they aren't technically "challenge-response". These little dogtag-sized chips just print out a cyclic number every 60 seconds. They adapt themselves to applications by "supplanting" the password mechanism. If your password is "cookie", you would type "cookieNNNNNN" into whatever password dialog box you liked. Their server knows to chop the last six digits off, try that against its crypto algorithm, and try the rest of it against the password db.

The thing I hate in general about this kind of token is that if you get logged out, you're screwed and have to wait for the next token to come up. Even worse, if you're logging in over a slow session (think cases of extreme processor slog) it's entirely possible that by the time you're prompted for your password, or by the time the system gets around to calling the authenticator, it will have expired.

Any discussion about this stuff cannot ignore S/Key or OPIE, which stands for "Onetime Passwords in Everything". This IS totally open-source, and I use it, especially in places where I don't trust the computer or the network. But it's more complex than it needs to be. In my setup, opie can be used WITHOUT ever typing your real password, so it's not quite two-factor. It's not so much about making the auth stronger, as it is about making eavesdropping useless.

Ten years ago, this was james-bond kind-of stuff, or at the very least, large-enterprise and government-contractor grade. Now, with phishing and social engineering on the rise, and people just Not Getting Any Smarter, you can get one of these things to protect your paypal account, or even your World of Warcraft Account.

I should note that it's getting increasinly common to see this done as a cell-phone app. Either one that runs over sms, and generates a key on the fly, or an app that emulates a hardware token. In general, I'm not a fan of this because SMS is forgeable, and people never, ever, lock their cellphones. Besides, having my server require a magic tamagotchi for a login is still cooler in my brain than requiring Another Piece of Software.

I've wanted to do token-based auth of some kind with my systems for a while. The two problems with this are: A) the software is expensive and B) the tokens are expensive. About a year ago, I discovered a company called MyPW, that makes a simple third-party auth answer. There's no software to buy, and they basically "loan" you the tokens, in exchange for charging a very small fee for each auth request. The tokens (and ostensibly, the software) they use are made by a company I hadn't previously heard of, called Vasco. While the algorithm the tokens use is still not open, and it appears thus, impossible to write your own implementation, at least, at the entry cost of ten dollars, Anyone Can Do This.

I've ordered some tokens, and in my excitement, have started looking at implementation details. To quote taylor swift..."And then I wasn't excited anymore." In reading up on this, I've discovered the following:

  • Near as I can tell, not every SSH client implementation has the ability to display these kinds of challenges to users. However, there's an RFC for it, so that's cool. And apparently, that RFC does specify that multiple challenges can be presented, at least in ssh version two (which everyone should be using).

  • Looking over a few things, it seems as though I can do multiple prompts for a user, with ssh (I'll have to testbed this somewhere), but it's not clear to me how the mypw Pam Module prompts a user. However, some other systems, like Webmin, are only configured to do straight HTTP auth. And I rather like that a user cannot see any part of webmin without answering the http query. (I should also note that my webmin instances don't use system passwords, as a failsafe in case something mangles the password file).

  • I can't find a pam-wise way of doing things the "RSA Way" (i.e. with your password and your token-key mishmashed).
    Surprising, really.

  • I also can't find a way that Pam Module A can modify the user's supplied password on the stack before passing it to Module B. This may totally be possible, if coded into the module itself, I just don't see a config-wise way of doing it, and don't understand the pam api well enough.

  • I think the way openssh makes its calls to pam, there could be an issue. What happens if I am prompted for my password, and get it right, then my tokenid, but get it wrong? I believe the pam stack starts over from the top, which means I have to re-type my password. Look at this the other way around. Let's say my tokenid is first, and I type it right, but I mangle my password. I have to then wait, since the system won't accept the same id twice. Allowing the pam module to maintain a cache, and permit on subsequent auths doesn't help either, since pam has (as far as I know) no concept of ip addresses or sessions. (In other words, I don't think pam can differentiate between subsequent auths on the same session, and a completely different auth session from a different machine).

Finally, in the "readme" that mypw supplies, they say to implement your pam setup as follows:

#%PAM-1.0
auth       required     pam_xmlrpc.so service=system-auth
#auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth

I see at least a few things wrong here.

  1. The service=system-auth thing only applies to pam_stack, so it's probably a typo. It's a minor typo, but this is the documentation for how to let people securely log into your server, so I kinda expect a little polishing.

  2. To look at this, this basically appears to act ONLY on the token-based password, which is inherently LESS secure than anything else. After all, if you steal my car keys, there's my WHOLE password sitting in plain text, you just have to guess my username.

Other missing things include:

  1. A way to define from the pam.conf file where the config file lives.
  2. A list of what options the pam module supports.
  3. A manpage.
  4. A definition for how to determine what happens if the auth server can't be contacted.
  5. A neat way for users to manage their own tokens.
  6. A way to support user-tokens via home-directory file instead of one-big-system file.
  7. The one-big-system-file approach, since it's a text file, doesn't scale. It should probably get some kind of db-file support.
  8. A way to manage "drift", i.e. how far expired a token may be. (That is, for slow and laggy connections, I'd like to see the option to still make a password one-time-only, but allow its use up to five minutes past its prime).

I think I'm going to write to these guys and suggest that they try to push in a FreeBSD port, as well as bringing this blog post to them.

Thsi looks like a fairly basic project to work with C on, if I spoke it...but I'm not comfortable cutting my teeth on such a critical piece of software. I guess I'll see what they say.

gushi: (Default)

So everyone knows I like SpamAssassin. Anyone with a hosting account on prime also knows that the prefs are stored in a SQL database on another server quark.

About two days after I switched over to this system, I wrote a simple tool, UpdatePrefs, that basically takes your user_prefs file from spamassassin and dumps them up to the database server. (It can also "fetch" your rules, for legacy compatibility -- I wanted a way out if I had to abandon the SQL thing).

Naturally, when I write a util like this, I post to the SpamAssassin mailing list. No response whatsoever.

I FINALLY heard from SOMEONE about this a couple days ago:

[11:53:59] * trjh [User] is now online =)

[11:53:59] trjh: hello. if you wouldn't mind, i'd like to ask you about the updateprefs.pl script you mentioned in May '05 on the spamassassin-users mailing list?

[11:53:59] -larpGM- [Away for 9:47m] Must have stepped out...

[11:56:31] larpGM: Heya

[11:56:37] larpGM: about time I heard from someone on that.

[11:57:09] trjh: i'm just converting my own personal setup to use sql (hoping it'll speed up the dog-slow performance on my 7-yr-old freebsd box)

[11:57:36] trjh: it's taken me half an hour to find any reference to anything like that. i'm shocked your script isn't in the spamassassin distribution and mentioned in the README.

[11:58:15] trjh: anyway, i ask because it isn't where you said it was then :) (www.gushi.org/updateprefs.pl)

[12:11:22] larpGM: Gimme a sec, lemme see if I can find it.

[12:13:23] trjh: np, thank you.

[12:14:11] larpGM: as a warning, it's still slightly unpolished.

[12:15:36] larpGM: http://www.gushi.org/updateprefs.pl

[12:15:52] larpGM: it was actually symlinked to the binary, which I moved from updateprefs.pl to updateprefs

[12:16:07] trjh: not a worry, thank you!

[12:17:24] larpGM: it's short and relatively sweet

[12:17:48] larpGM: also, I found when I moved to SQL, I just had to accept the reality that my bayes corpus had to be rebuilt.

[12:18:15] larpGM: but then, mine were huge

[12:18:15] trjh: sa-learn --restore didn't do the trick?

[12:20:21] larpGM: nope

[12:20:28] larpGM: I cut my losses, this was a while ago too

[12:21:24] trjh: would you mind if i put a reference to your message & script here? http://wiki.apache.org/spamassassin/BetterDocumentation/SqlReadme ("Dan Mahoney wrote a perl script to convert user_prefs from file to database format. He mentions it here and it can be found here.")

[12:23:12] larpGM: Sure.

[12:23:14] larpGM: feel free

[12:23:38] larpGM: I'm generally very embittered with the SA mailing lists. I post intelligent things, and get no response.

[12:23:43] larpGM: I post errors, get no response.

[12:25:49] larpGM: keeping in mind you're the first person who's asked about this should-be-commonsense utility in as longas it's been since I wrote this.

[12:48:08] trjh: maybe nobody upgrades. maybe they all write it from scratch :)

[12:48:42] larpGM: possibly

[12:48:47] larpGM: note when I posted it.

[12:49:02] trjh: i did alright.

[13:03:57] trjh: duly updated. you might add a comment or two at the top of your script, something like i've just added on my local copy:

[13:04:00] trjh: # written by Dan Mahoney

[13:04:03] trjh: # http://www.gushi.org/updateprefs.pl

[13:04:21] trjh: anyway, you're now closer to the SA canon than you were before :)

Ah well, better late than never I suppose.

gushi: (Default)

So everyone knows I like SpamAssassin. Anyone with a hosting account on prime also knows that the prefs are stored in a SQL database on another server quark.

About two days after I switched over to this system, I wrote a simple tool, UpdatePrefs, that basically takes your user_prefs file from spamassassin and dumps them up to the database server. (It can also "fetch" your rules, for legacy compatibility -- I wanted a way out if I had to abandon the SQL thing).

Naturally, when I write a util like this, I post to the SpamAssassin mailing list. No response whatsoever.

I FINALLY heard from SOMEONE about this a couple days ago:

[11:53:59] * trjh [User] is now online =)

[11:53:59] trjh: hello. if you wouldn't mind, i'd like to ask you about the updateprefs.pl script you mentioned in May '05 on the spamassassin-users mailing list?

[11:53:59] -larpGM- [Away for 9:47m] Must have stepped out...

[11:56:31] larpGM: Heya

[11:56:37] larpGM: about time I heard from someone on that.

[11:57:09] trjh: i'm just converting my own personal setup to use sql (hoping it'll speed up the dog-slow performance on my 7-yr-old freebsd box)

[11:57:36] trjh: it's taken me half an hour to find any reference to anything like that. i'm shocked your script isn't in the spamassassin distribution and mentioned in the README.

[11:58:15] trjh: anyway, i ask because it isn't where you said it was then :) (www.gushi.org/updateprefs.pl)

[12:11:22] larpGM: Gimme a sec, lemme see if I can find it.

[12:13:23] trjh: np, thank you.

[12:14:11] larpGM: as a warning, it's still slightly unpolished.

[12:15:36] larpGM: http://www.gushi.org/updateprefs.pl

[12:15:52] larpGM: it was actually symlinked to the binary, which I moved from updateprefs.pl to updateprefs

[12:16:07] trjh: not a worry, thank you!

[12:17:24] larpGM: it's short and relatively sweet

[12:17:48] larpGM: also, I found when I moved to SQL, I just had to accept the reality that my bayes corpus had to be rebuilt.

[12:18:15] larpGM: but then, mine were huge

[12:18:15] trjh: sa-learn --restore didn't do the trick?

[12:20:21] larpGM: nope

[12:20:28] larpGM: I cut my losses, this was a while ago too

[12:21:24] trjh: would you mind if i put a reference to your message & script here? http://wiki.apache.org/spamassassin/BetterDocumentation/SqlReadme ("Dan Mahoney wrote a perl script to convert user_prefs from file to database format. He mentions it here and it can be found here.")

[12:23:12] larpGM: Sure.

[12:23:14] larpGM: feel free

[12:23:38] larpGM: I'm generally very embittered with the SA mailing lists. I post intelligent things, and get no response.

[12:23:43] larpGM: I post errors, get no response.

[12:25:49] larpGM: keeping in mind you're the first person who's asked about this should-be-commonsense utility in as longas it's been since I wrote this.

[12:48:08] trjh: maybe nobody upgrades. maybe they all write it from scratch :)

[12:48:42] larpGM: possibly

[12:48:47] larpGM: note when I posted it.

[12:49:02] trjh: i did alright.

[13:03:57] trjh: duly updated. you might add a comment or two at the top of your script, something like i've just added on my local copy:

[13:04:00] trjh: # written by Dan Mahoney

[13:04:03] trjh: # http://www.gushi.org/updateprefs.pl

[13:04:21] trjh: anyway, you're now closer to the SA canon than you were before :)

Ah well, better late than never I suppose.

August 2017

S M T W T F S
  12345
678 9101112
13141516171819
20212223242526
27 28293031  

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 23rd, 2017 09:02 am
Powered by Dreamwidth Studios