Challenge response support for the yubico pam module
Tollef Fog Heen
Hi,
has anybody taken a shot at adding challenge/response support to the PAM
module yet?
Cheers,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Simon Josefsson
> Hi,
>
> has anybody taken a shot at adding challenge/response support to the PAM
> module yet?
Hi. Not that I know of -- but it sounds like a good idea! Validating
the response is a bit different than validating a normal OTP against a
server, but at least something could be done.
/Simon
Tollef Fog Heen
Is there any support for challenge response in the validation protocol
yet? I couldn't find anything.
I would naively imagine something like:
- get challenge from API server using
http://api.yubico.com/wsapi/2.0/challenge (or similar) with the
yubikey user id (except we don't have this yet?)
- send challenge to yubikey
- send response back to server which acks/nacks the request.
Maybe it'll in reality be something more like:
- get challenge from API server using
http://api.yubico.com/wsapi/2.0/challenge (or similar). Server
generates a random challenge
- send challenge to yubikey
- send response + challenge back to server which acks/nacks the request.
Or we could have the local agent generate the challenge, there might not
be any benefit in having the server do it. Has it been documented how
you'd envision this fitting into the authentication landscape?
Regards,
Fredrik Thulin
...
> Is there any support for challenge response in the validation protocol
> yet? I couldn't find anything.
>
> I would naively imagine something like:
>
> - get challenge from API server using
> http://api.yubico.com/wsapi/2.0/challenge (or similar) with the
> yubikey user id (except we don't have this yet?)
> - send challenge to yubikey
> - send response back to server which acks/nacks the request.
What would it add to do C/R with the Yubico validation servers? We
already have authentication using those =).
I think it would be more beneficial if C/R in Yubico-PAM should aim to
support offline validation.
A colleague has written a document targeting a different audience
(full disk encryption), but the principle idea for authentication (and
authorization) using C/R is the same. I've been battling with our web
CMS system today to try and put the document up for download so I
could share a link here, but in the mean time I'll send you the
document using private e-mail. Anyone else interested should let me
know.
/Fredrik
Tollef Fog Heen
| On Fri, Mar 11, 2011 at 7:09 PM, Tollef Fog Heen <tfh...@err.no> wrote:
| ...
| > Is there any support for challenge response in the validation protocol
| > yet? I couldn't find anything.
| >
| > I would naively imagine something like:
| >
| > - get challenge from API server using
| > http://api.yubico.com/wsapi/2.0/challenge (or similar) with the
| > yubikey user id (except we don't have this yet?)
| > - send challenge to yubikey
| > - send response back to server which acks/nacks the request.
|
| What would it add to do C/R with the Yubico validation servers? We
| already have authentication using those =).
Good point. :-)
| I think it would be more beneficial if C/R in Yubico-PAM should aim to
| support offline validation.
Yeah, indeed.
I've implemented something along the lines of what we've talked about in
private mail at https://github.com/tfheen/yubico-pam. Feedback is most
welcome.
It needs some documentation and I want to store a hashed expected
response, not the actual expected response in the per-user file.
Fredrik Thulin
> private mail at https://github.com/tfheen/yubico-pam. Feedback is most
> welcome.
>
> It needs some documentation and I want to store a hashed expected
> response, not the actual expected response in the per-user file.
To let others in on the discussion : what we talked about in private
e-mail was mostly how to make challenge response for offline
authentication in yubico-pam able to unlock home directories encrypted
with ecryptfs for example. That would be really useful and definitely
doable, although it is not without it's challenges (ha ha).
The first choice is between always sending the same challenge to the
Yubikey or not. Always sending the same would make it somewhat like a
static password, but a lot more secure. The response wouldn't be as
easily stolen by someone with temporary physical access to the key,
since they would have to know the challenge.
Not having a static challenge introduces the next choice. Have the
HMAC key available (but protected) on the host computer or not? A
system could be built with "rolling" challenges, where the next
expected response is stored on the host together with the next
challenge.
The next expected response could be determined in two ways. The HMAC
key could be stored on the host encrypted with the next expected
response. Each time the correct response (r1) is presented by the
Yubikey, the HMAC secret would be decryptable and a new challenge (c2)
could be constructed and the new expected response (r2) computed and
used to re-encrypt the HMAC secret.
An alternative to not have to have the HMAC key on the host is to
follow up each successful C/R (c1 + r1) with another challenge to the
Yubikey (c2) to get the next response (r2). This would be vulnerable
to USB sniffing attacks, but perhaps that is not a valid concern since
someone with USB sniff access would probably also have host root
account access, and then be able to steal the ecrypts decryption key
somehow anyways.
Since ecryptfs (I'm assuming) expects to get the same input (password)
every time to decrypt the users home directory, rolling
challenge-responses can't be used as input directly. I'm thinking the
most complete solution would be that of the FDE (full disk encryption)
document my colleague wrote (which I'll post a link to as soon as I
can) - use r2 to encrypt a file containing some known/verifiable plain
text plus the ecryptfs decryption key.
The way to verify that the correct response is received is to test if
r2 can be used to decrypt the file.
What do you think?
/Fredrik
Fredrik Thulin
>
> It needs some documentation and I want to store a hashed expected
> response, not the actual expected response in the per-user file.
a few thoughts :
* We should (optionally) support registering multiple YubiKeys for a
user. Perhaps use the YubiKey serial number (available through API
call in libykpers) to index different challenges and expected
responses?
* The fscanf parsing doesn't feel robust enough (it often broke for me
when testing), and it produces compiler warnings.
* The updating of the C/R state file needs locking, to support
multiple parallel logins.
Also, as a FYI to you all, I've got a draft implementation that uses
YubiKey C/R to provide a more secure PAM authtok than the user
password. In plain English, this means you can use a YubiKey to
decrypt your eCryptfs encrypted home directory! To try it out :
$ git clone -b feature/chalresp_authtok_generation \
git://github.com/fredrikt/yubico-pam.git
Short introduction is currently available in the source code, see this
commit :
https://github.com/fredrikt/yubico-pam/commit/476767a5cb59fa0bb27ad2d99e276c0066cd044b
/Fredrik
Tollef Fog Heen
| On Mar 12, 3:58 pm, Tollef Fog Heen <tfh...@err.no> wrote:
| ...
| > I've implemented something along the lines of what we've talked about in
| > private mail athttps://github.com/tfheen/yubico-pam. Feedback is most
| > welcome.
| >
| > It needs some documentation and I want to store a hashed expected
| > response, not the actual expected response in the per-user file.
|
| Besides the contents of the pull request I sent you on Github, I have
| a few thoughts :
I've merged most of it now. I don't want to fail authentication if we
can't write a new challenge, though, as that might make logins fail if
the disk is completely full.
| * We should (optionally) support registering multiple YubiKeys for a
| user. Perhaps use the YubiKey serial number (available through API
| call in libykpers) to index different challenges and expected
| responses?
Sounds reasonable.
| * The fscanf parsing doesn't feel robust enough (it often broke for me
| when testing), and it produces compiler warnings.
Yeah, there's a bunch of compiler warnings now, we should probably get
them fixed. I don't know why gcc complains about the fscanf one, since
it's safe and it should be able to see that.
| * The updating of the C/R state file needs locking, to support
| multiple parallel logins.
That's a headache I've left for others. :-) The current one will at
least never lead to corrupted files, but last-one-wins, which isn't that
great, but shouldn't be a problem in practice.
| Also, as a FYI to you all, I've got a draft implementation that uses
| YubiKey C/R to provide a more secure PAM authtok than the user
| password. In plain English, this means you can use a YubiKey to
| decrypt your eCryptfs encrypted home directory! To try it out :
Nice! I'd love to see pam_mount integration too, since that gets us
luks support so the user can have a normal password in addition to the
challenge-response auth. Much safer when testing. :-)
Regards,
Fredrik Thulin
> can't write a new challenge, though, as that might make logins fail if
> the disk is completely full.
Are you sure login won't fail anyways if the disk is completely full?
On this topic, the current code uses fsync() after overwriting the C/R
state file to try to make sure the file is OK on disk.
Isn't it so that with journaling file systems, the contents of a file
being updated when something crashes can get destroyed but metadata
updates are guaranteed to be atomic? If that's not just a
misunderstanding on my part, a safer way to do this would be to write
a new file alongside the old one, fsync() the new file and then do a
rename().
...
> | Also, as a FYI to you all, I've got a draft implementation that uses
> | YubiKey C/R to provide a more secure PAM authtok than the user
> | password. In plain English, this means you can use a YubiKey to
> | decrypt your eCryptfs encrypted home directory! To try it out :
>
> Nice! I'd love to see pam_mount integration too, since that gets us
> luks support so the user can have a normal password in addition to the
> challenge-response auth. Much safer when testing. :-)
pam_mount seems to use pam_get_item(pamh, PAM_AUTHTOK, ...) to get the
mount credential, so chances are it already works.
I have no idea how to use pam_mount. If can you send me some sample
config I can try it out, if you don't want to do that yourself.
/Fredrik
Tollef Fog Heen
| On Wed, Mar 16, 2011 at 11:01 PM, Tollef Fog Heen <tfh...@err.no> wrote:
| ...
| > I've merged most of it now. I don't want to fail authentication if we
| > can't write a new challenge, though, as that might make logins fail if
| > the disk is completely full.
|
| Are you sure login won't fail anyways if the disk is completely full?
If so, that's a bug.
| On this topic, the current code uses fsync() after overwriting the C/R
| state file to try to make sure the file is OK on disk.
If you're exceedingly unlucky with your system crash, I believe the
current (as in, pre 1364b39db787d9c78f56f6eb3ba95026d84386a9) can leave
you with an challenge file.
| Isn't it so that with journaling file systems, the contents of a file
| being updated when something crashes can get destroyed but metadata
| updates are guaranteed to be atomic? If that's not just a
| misunderstanding on my part, a safer way to do this would be to write
| a new file alongside the old one, fsync() the new file and then do a
| rename().
Indeed, which is why I'm doing that in 1364b39.
| ...
| > | Also, as a FYI to you all, I've got a draft implementation that uses
| > | YubiKey C/R to provide a more secure PAM authtok than the user
| > | password. In plain English, this means you can use a YubiKey to
| > | decrypt your eCryptfs encrypted home directory! To try it out :
| >
| > Nice! I'd love to see pam_mount integration too, since that gets us
| > luks support so the user can have a normal password in addition to the
| > challenge-response auth. Much safer when testing. :-)
|
| pam_mount seems to use pam_get_item(pamh, PAM_AUTHTOK, ...) to get the
| mount credential, so chances are it already works.
Ok, sounds good.
| I have no idea how to use pam_mount. If can you send me some sample
| config I can try it out, if you don't want to do that yourself.
Install libpam-mount, then put something like:
<volume fstype="crypt" path="/dev/mapper/qurzaw-home1" mountpoint="/home"
user="tfheen" />
near the bottom of the file. path is the encrypted block device,
mountpoint is where it should be mounted, user is for which user to
mount this.
Fredrik Thulin
> ]] Fredrik Thulin
>
> | On Wed, Mar 16, 2011 at 11:01 PM, Tollef Fog Heen <tfh...@err.no> wrote:
> | ...
> | > I've merged most of it now. I don't want to fail authentication if we
> | > can't write a new challenge, though, as that might make logins fail if
> | > the disk is completely full.
> |
> | Are you sure login won't fail anyways if the disk is completely full?
>
> If so, that's a bug.
I'm sorry - that was not a fair question (unintentional) - no one can
be sure logins won't fail if X or Y.
You have a point. I was only thinking of X windows logins, which in my
experience quite often fail when the disk is full. Console logins
usually works, and if they don't I agree it is a bug somewhere.
Anyways, your opinion in this matter is worth as much as mine, so
let's just do it your way.
...
> | Isn't it so that with journaling file systems, the contents of a file
> | being updated when something crashes can get destroyed but metadata
> | updates are guaranteed to be atomic? If that's not just a
> | misunderstanding on my part, a safer way to do this would be to write
> | a new file alongside the old one, fsync() the new file and then do a
> | rename().
>
> Indeed, which is why I'm doing that in 1364b39.
Fantastic =) - I hadn't seen that commit.
I was thinking of what would be needed to actually release this new
functionality. There is some documentation of at least the new
parameters missing (and ideally another Wiki-page for offline
authentication), but I also thought it would be quite a bit more user
friendly to provide a tool to setup C/R for a user.
I've implemented such a tool (called ykpamcfg unless someone comes up
with a better name) that makes it a one-liner to configure your
account with an initial challenge and expected response from a
YubiKey.
I also added YubiKey serial number to the C/R state filename, to allow
for multiple YubiKeys being used by a single user (e.g. a backup key,
or a user plus an administrator).
The tool shared lots of code with the PAM module, so I moved lots of
C/R code to util.c - I hope you concur.
I'll send a pull request again, but please merge these changes (and
improve anything you feel needs improving ;) ) and tell me when you
want me to merge it all back into the official source tree.
/Fredrik
Tollef Fog Heen
Hi,
| You have a point. I was only thinking of X windows logins, which in my
| experience quite often fail when the disk is full. Console logins
| usually works, and if they don't I agree it is a bug somewhere.
|
| Anyways, your opinion in this matter is worth as much as mine, so
| let's just do it your way.
I've now implemented so if the updating fails for any reason (the user
yanking the key too quickly, disk full, whatever), we tell them. Of
course, they might well ignore it, but there's not really anything more
we can do. This is using the pam conversation function so it should
work with all apps (I tested gdm and su, both worked).
| I was thinking of what would be needed to actually release this new
| functionality. There is some documentation of at least the new
| parameters missing (and ideally another Wiki-page for offline
| authentication), but I also thought it would be quite a bit more user
| friendly to provide a tool to setup C/R for a user.
Docs are useful, yes.
| The tool shared lots of code with the PAM module, so I moved lots of
| C/R code to util.c - I hope you concur.
Yup, makes sense. Maybe we should call it yubikey-cr-register
yubipam-register or something along those lines? yubico-pam-register-key
is a bit on the long side.
| I'll send a pull request again, but please merge these changes (and
| improve anything you feel needs improving ;) ) and tell me when you
| want me to merge it all back into the official source tree.
I've merged my bits now and added a missing fflush in util.c, so it
should get a bit of testing before we call it a release, but apart from
that it looks pretty ready to me.
Fredrik Thulin
> yanking the key too quickly, disk full, whatever), we tell them. Of
> course, they might well ignore it, but there's not really anything more
> we can do. This is using the pam conversation function so it should
> work with all apps (I tested gdm and su, both worked).
Super!
...
> | The tool shared lots of code with the PAM module, so I moved lots of
> | C/R code to util.c - I hope you concur.
>
> Yup, makes sense. Maybe we should call it yubikey-cr-register
> yubipam-register or something along those lines? yubico-pam-register-key
> is a bit on the long side.
I think there is potential we will be adding more administrative tasks
to that command later on, so a more generic name is probably good. It
already takes a -A argument for the action requested, but -A only
supports (and defaults to) add_hmac_chalresp today. Other commands
I've thought about are 'list_all_my_yubikeys', 'revoke_a_yubikey',
'revoke_all_yubikeys' etc.
> | I'll send a pull request again, but please merge these changes (and
> | improve anything you feel needs improving ;) ) and tell me when you
> | want me to merge it all back into the official source tree.
>
> I've merged my bits now and added a missing fflush in util.c, so it
> should get a bit of testing before we call it a release, but apart from
> that it looks pretty ready to me.
I agree - it's shaping up really good. Both the C/R authentication and
my other branch for eCryptfs authentication token generation. I've
received some positive feedback about that feature on the
ecryptfs-users mailing list as well.
/Fredrik
Tollef Fog Heen
| > | The tool shared lots of code with the PAM module, so I moved lots of
| > | C/R code to util.c - I hope you concur.
| >
| > Yup, makes sense. Maybe we should call it yubikey-cr-register
| > yubipam-register or something along those lines? yubico-pam-register-key
| > is a bit on the long side.
|
| I think there is potential we will be adding more administrative tasks
| to that command later on, so a more generic name is probably good. It
| already takes a -A argument for the action requested, but -A only
| supports (and defaults to) add_hmac_chalresp today. Other commands
| I've thought about are 'list_all_my_yubikeys', 'revoke_a_yubikey',
| 'revoke_all_yubikeys' etc.
I have a slight preference for subcommands for each little thing
(possibly wrapped in a similar fashion to how git does it), but your way
works fine as well.
| > | I'll send a pull request again, but please merge these changes (and
| > | improve anything you feel needs improving ;) ) and tell me when you
| > | want me to merge it all back into the official source tree.
| >
| > I've merged my bits now and added a missing fflush in util.c, so it
| > should get a bit of testing before we call it a release, but apart from
| > that it looks pretty ready to me.
|
| I agree - it's shaping up really good. Both the C/R authentication and
| my other branch for eCryptfs authentication token generation. I've
| received some positive feedback about that feature on the
| ecryptfs-users mailing list as well.
That's great. If you merge it all so we have a common tree to test
again and do that over the next week with a goal of getting a release
out the week after or so?
Fredrik Thulin
> again and do that over the next week with a goal of getting a release
> out the week after or so?
I'll do that, although I have some other things I have to finish first.
/Fredrik