Closed (won't fix)
Project:
YubiKey
Version:
6.x-2.0
Component:
User interface
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
13 Feb 2011 at 21:53 UTC
Updated:
30 Jul 2012 at 03:09 UTC
Jump to comment: Most recent file
Comments
Comment #1
toddejohnson commentedThe 2.x branch was an attempt to merge the more functional project from http://code.google.com/p/yubikey-drupal/ into the official Drupal project as it fixed several open issues and added more functionality.
On a personal note, I considered that functionality a flaw of the software as you were not gaining any security improvement and users of the module might not know of that insecure "functionality."
Is this functionality required for your use case or would one of the other methods suffice?
2.x methods:
Comment #2
cafuego commentedWell, I don't use the module so much to provide extra security for each login, as to give me a safe way to login via my YubiKey when I'm on a hostile network (ie: not in the office)
What other users (without admin access) do really doesn't matter that much to me. They just have a login so they can leave comments without needing to go through a captcha.
So with the options currently I either have to provide a secure OTP and my login details or use OTP only and be put in the position where non-admins can no longer login, as they don't have a YubiKey.
If I lose my YubiKey and someone hacks into my account, well that's my fault - not a software problem ;-)
Of course, I can stay on the 6.x-1.x branch if you don't think this functionality should be in 2.x.
Comment #3
toddejohnson commentedA valid argument deserves code. I will see if I can get this added soon. Thank you for you help testing and reporting bugs.
Comment #4
toddejohnson commentedI'm attaching a patch as this eats into the authentication mechanisms. Please help me test this in all authentication modes and verify there are no tricks around the chosen authentication scheme.
Note the added yubikey-legacy files they are from the 1.x branch and I was in too much of a hurry to integrate them. They work, but I feel it is a ugly hack. I'm open to suggestions and better patches.
Comment #5
tim_djI am seeing this only now since I've just upgraded our Yubikey to 2.0.
This is indeed a functionality we have been using to to make it easy for our clients to login.
Especially since they login on different computers in different places.
The patch is not working anymore since it was written for beta-2 could you by any chance diff it to 2.0? I would be willing to test it.
Comment #6
Leeteq commentedIf this issue involves altering the authentication scheme, I assume it should be dealt with in 7.x first and then backported? Changing branch accordingly.
I think that the option "(User name + Password) or Yubikey" is practical to have in certain situations, especially after #1060580: Yubikey per role lands. Then for example user roles that does not have access to critical security features can be given a lower level security login option on sites that does not contain "sensitive" information or the like.
Addition: I would also like the following option:
"(Email + Yubikey OTP) or (Yubikey OTP + Password)"
- where in that case "User name" will _not_ be accepted, even if the user name field description says "User name OR email". (Ideally, that description should be overridden for this variant.) One has to provide (and thus know) the email.
Further on this:
Integration with for example the http://drupal.org/project/multiple_email module, so that each user account can have one specific, dedicated email address to work with yubikey and password retrievals. The other emails, including the primary email, should be possible to block from password retrievals if specified in the Yubikey settings. That would be a separate feature request, I assume.
Comment #7
thegrue commentedHello,
my problem with the new version of the yubikey-module is the same as cafuegos . In fact, I may have to disable the module completely on my site (www.maennerchor-kirchseeon.de), because it is much too intrusive for my users. They can barely cope with normal authentication and now there's a completely new field with a thing they don't know - so they fail to log in because they enter "something" into the yubikey field.
The old behaviour where I had to click on the yubikey link was much better. I would even be happy about the two factor authentification, if it were hidden behind a link.
The openid module gets it right :)
Hmmm. I see my post looks a bit like a rant. Let me assure you it isn't ;) I like the yubico module, the old version was just better :)
Comment #8
toddejohnson commentedThis mode unless it can cleanly be added will be depreciated. This patch against 6.x-2.0 will be as far as I'm going to bring this as I feel it is dirty. Dirty code and auth don't belong together.
@tim_dj I just tested the patch against 6.x-2.x's branch and it applied cleanly. Please provide the output of the patch command if you have problems.
@Leeteq I don't feel that the email + OTP provides any extra security. You might as well use the yubikey on it's own. As to the multiple email integration please open a new ticket and explain in further detail.
@TheGrue The 2.x branch was a merge of the offical project(as stated above). My concern with that functionality was the requirement of javascript to dynamicly change the form. Something else I don't feel was clean. Feel free to provide a patch/suggestions to simplify or improve the user experience in another ticket.
The code is just too messy for me to trust and want to checkin. Also as nobody has posted any comments of review. Due to the above I'm closing this as a won't fix.