request: TOTP (2FA)

[r2evans]

I had initially suggested this in http://tools.ltb-project.org/issues/818. For reference:

Provide 2FA (TFA) as an option for verification of the user. There are some 2FA PHP modules (https://github.com/RobThree/TwoFactorAuth, https://github.com/PHPGangsta/GoogleAuthenticator) that provide sufficient access to implement it.

(It appears that the second link hasn't been touched in a couple of years, perhaps RobThree's would be preferred?)

I recognize it is not necessarily a top priority for all (or perhaps many, even), so I was considering how hard it would be to implement. Some questions I had:

• How to store the shared secret?
  • Can it be stored within an unmodified LDAP structure? Requiring a change to the schema will many (if not most).
  • Ditto for Active Directory? (I believe AD is for the most part LDAP-compatible, but this question begs MS's AD or Samba4's AD.)
  • If neither of the above, I'm not fond of having yet another storage mechanism, whether it be on a SQL server somewhere or in a local-only SQLite database.
• If it can be stored within LDAP, is it a mechanism that other applications might be able to use? For instance, apps like owncloud, nextcloud, and gitlab have various levels of 2FA support, but I believe they are storing it internally/proprietarily. I think it would be good to be able to use the same shared-secret across multiple clients. (Then, of course, I'd need to convince those apps to get the shared-secret and use it ...)
• Again, if it can be stored within the LDAP structure, is it "safe enough" to store it there? Are there security considerations I'm not considering?

The current method of using SMS as a reset mechanism is useful but this sort of 2FA is no longer recommended. I'm inferring that this should also apply to email-based OOB reset links, for similar reasons.

Thoughts?

[coudot]

Yes this is interesting but clearly not a priority for the moment.

[aurbjo]

Just to let you know, SecurEnvoy 2FA uses the telexNumber attribute i AD to store the shared secret, this is an attribute that is most likely not used by anyone and most people don't even know it exists. Makes it very easy to check for users with 2FA enabled as all users that have not null in the telexNumber field are enabled.

[r2evans]

@aurbjo thanks for the feedback (https://www.securenvoy.com/ for reference). @coudot, it's a subscription service, though I don't think aurbjo was suggesting it as anything other than a place to stash the token.

I don't find that field in my AD schema, so I don't know if it's easy enough to add it ad hoc or if the schema needs to be formally updated (which was more the point of my first post here). Coudot, since you're the expert here on LDAP, can you say if it's easy, it's hard, or "it depends"?

I'm sure you haven't been able to put a lot of thought to this yet. Would you envision 2FA being a component added on to others? For example, after sendsms or sendtoken (and pre-registered 2FA), the user would be asked for "new password", "confirm new password", and "2FA code".

Rationale: SMS-based 2FA has been deprecated by itself and email-based links are just as susceptible. However, compounding with TOTP would make it a little harder to break.

Thanks again, v1.0 is working like a champ!

[coudot]

I would indeed prefer to implement TOTP or HOTP because these are standards and you could use a free client like FreeOTP to use it.

OTP is quite like a captcha: an additional check. So we could add an option to add OTP in forms like we already do for captcha.

Links to check for the server-side implementation:

• https://www.multiotp.net/website/
• https://github.com/lelag/otphp

[r2evans]

The latter is unmaintained, recommending a still-maintained fork: https://github.com/Spomky-Labs/otphp. Both seem fine, I haven't read enough to have an idea of which would be better.

For storing the token, does LDAP support adding arbitrary fields to a user's record? If not, is it necessary to update the schema or is it acceptable to hijack one of the existing fields?

[flhoest]

Very interesting post, I was actually here to search for such feature. Our company is requesting OTP when reseting password :-/
Any idea when this could be made available ?

[coudot]

OTP can be used either as a second authentication factor (kind like a captcha) or as a replacement of mail or SMS. In both cases a secret should be kept in LDAP user's entry.

I don't know how long it could take to implement the solution, but I'm not sure to be able to do it on my spare time.

[flhoest]

This is why they invented GitHub ;)

[r2evans]

@flhoest, does this mean you're planning to work on it? I have it on my todo list but haven't been able to commit time to it yet.

@coudot, this requires adding to the LDAP/AD schema. I suspect that since we need to create a new object class that inherits from an existing one, is it safe enough to assume organizationalPerson, or is inetOrgPerson better to use? Since I see neither in the SSP code, but is there a third I'm not considering?

[flhoest]

@r2evans: I'm afraid I do not have the skills. I'm just an advanced user.

[coudot]

@r2evans extending the schema is not mandatory. See the reset by questions feature, I coded it so we can use any objectClass/attribute to store/read the answer. You should not force someone to extend the schema, as you don't know which kind of LDAP directory he is running (OpenLDAP, AD, etc.)

[r2evans]

Thanks for the pointer. I've been trying to learn the code but get an LDAP error.

Using command-line php (actually, psysh), I manually load all of index.php and pages/setquestions.php in order to connect successfully to the AD. I connect with my user, not the admin user (or manager), I think this is the correct method.

I set a question to be:

>>> $userdata[$answer_attribute] = '{favice}vanilla';
>>> $userdata
=> [
     "objectClass" => [
       "top",
       "person",
       "organizationalPerson",
       "user",
       "extensibleObject",
     ],
     "info" => "{favice}vanilla",
   ]

("favice" is defined as $messages["questions"]["favice"] = ... in conf/config.inc.php.)

However, when I get down to:

    # Commit modification on directory
    $replace = ldap_mod_replace($ldap, $userdn , $userdata);

I get:

PHP warning:  ldap_mod_replace(): Modify: No such attribute on line 1

(This happens with an array with either or both of objectClass and info.)

Should I be changing to the manager role at some point to be able to overwrite object attributes?

[coudot]

extensibleObject is not compatible with AD, you need to choose an objectClass and/or an attribute compatible with AD schema.