gushi: (tall no good)

TL;DR: If you have a thing that's broken for you, contact me and we'll figure out a fix. If you have a DB-based thing or a PHP-based thing, this is likely.

If you have a thing that's broken for you, contact me and we'll figure out a fix. If you have a DB-based thing or a PHP-based thing, this is likely.

Upgrades last night went well, but a few things are being weird.

BSD Stupidity

  • For some reason, pkg upgrade didn't reinstall proftpd. Easily enough fixed, but if it missed that, it may have missed other things.

  • Mysql didn't get upgraded from 5.5 to 5.6, but all the php stuff was linked against 5.6, so I manually upgraded mysql-server to 5.6 and ran a bunch of upgrade scripts.

  • Stupidly, the FreeBSD installer removed named.conf because BIND is no longer part of the base tree. DUMB. Like, there's no other reason a person would want that file? (Luckily, I had backed it up).

  • Also stupidly, trying to install bind9.11 tries to uninstall zkt. WTaF?

  • Freebsd-update wanting to overwrite my sendmail.cf (not MC, CF) was just plain dumb. Same with my ntp.conf. I think I'm just going to globally call a /usr/local/etc/ntp.conf in rc.conf, and let it stop complaining about any local changes.

  • Something tickles the password file that causes pkg's user-manipulations to fail, somehow getting the DB and the textfile out of sync.

  • People had warned me about my disk devices changing names, but as this is a VM with scsi-based vdisks this didn't affect me.

PHP Stupidity

  • PHP no longer likes mysql's built-in "old style" passwords. If you have a site that's DB-based and you've been hosted by me for like a LONG time, I'll need to do some tweaking on the backend for you.

  • PHP's session dir got weird again. I may need to define a startup script to fix perms on that. (Come to think of it, I should define a crontab to do cleanup on that anyway).

  • As usual, there's a number of deprecated and "removed" PHP functions. I'm vaguely contemplating building static versions of older versions of PHP from scratch to try and resolve these. Because I use suPHP, it lets me determine the PHP interpeter at a per-site or even per-file level. In a past life, this let me run php4 and php5 at the same time.

(Yes, an unstable version of php5.4 sticking around is arguably bad, but if it's a thing I only turned on for a given site that was otherwise broken and that site runs only as that user, I consider this fairly low risk).

Future Work

  • I've accepted that there's always going to be a couple of packages I need to build myself. That said, I should act like a proper port maintainer, and maintain "diff" files for them that are easily applied. I might even reach out to the official package maintainers on some of this stuff and see if they can be included.

  • Because this system started life using ports and pkg-classic, my packages have no idea which packages are "automatic" (i.e. were not explicitly installed, but merely installed as dependencies), so pkg autoremove may not work so well for me. At some point, I'll manually audit the dependency tree.

  • Squirrelmail's cert is marked as insecure because it's SHA1. I've put in for a reissue, but Geotrust is taking their sweet-ass time on it.

  • Now that I can support current state-of-the-art crypto, I'll likely do some cert tweaking for those things that use SSL. (Webmin, proftpd, Squirrelmail).

  • At some point, I really want to do a proof-of-concept that lets you accept weaker SSL settings, but redirect to a framed warning page. Because the default behavior of this (connection failed) just sucks.

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.

May 2017

S M T W T F S
  123456
78910111213
14151617181920
21222324252627
28293031   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 26th, 2017 02:40 am
Powered by Dreamwidth Studios