Discussing enhancements and changes for V3 rewrite

[eddyystop]

Transfer from https://github.com/feathers-plus/feathers-authentication-management/issues/114

[eddyystop]

Reserved.

[eddyystop]

[In design. Awaiting comments.]

(e) List of previous passwords, so they are not reused.

Questions:

• The a-l-m option userExtraPasswordFields is an array of password-like field names. The existing passwordField option is automatically added to the front of this list. This passwordField option is forced to authentication.local.passwordField in config/default.json if that exists.
• The countEachPasswordHistory a-l-m option specifies the number of entries in the passwordHistory array. What is a reasonable default?
• When a password is changed, the new password is immediately placed in passwordHistory. This makes checking simpler.
• The Date.now() timestamp of when the password was created is kept in passwordHistory?
• If we have password, PIN and badge password-like fields, should we differentiate between them in the array? Probably as that's the only way to prevent the history of a particular password-like field from being flushed.
  • That means we need to keep the name of the password-like field for each entry.
  • Each entry would be [ passwordLikeFieldName, Date.now(), hashedPassword ], stringified for SQL DBs, so the size can get significant.
  • A clean-up command would be needed in case the dev removes a password-like field from the list. The command would delete password history entries for fields not in the current list of password-like fields.

Related comments:

• The passwordChange, resetPwdLong, resetPwdShort commands would fail if a duplicate password was used when passwordHistory exists.
• Perhaps this feature can be implemented as a hook.

[eddyystop]

Reserved.

[claustres]

About multiple passwords I like your idea of somewhat considering we have a "master" password (the default field or another one we have chosen), then others are simply additional info attached to the identity we can only change giving the master password. This will avoid a lot of code and IMHO covers the use cases. Indeed having multiple "master" password does not make sense, people doesn't want to randomly use one or the other "just for fun". Si if they need additional "secrets" this is to be used in others things than the app itself (eg hardware lock) or to strengthen auth using both (it seems to me however already covered by MFA).

About password strength we have avoided using https://github.com/dropbox/zxcvbn in our product due to its english centric approach. Moreover, it seems to be a complement to a password policy, you can have a policy and still want to check strength, you can also enforce some password properties whatever the strength. I think you will have multiple use cases and integrating such opiniated lib is not a good idea IMHO.

[xendarboh]

I wanted to chime in before much more time passes. I'm excited to see this development, much thanks! I still need to digest details of the a-l-m article, plugin implementation, and recent comments here, so I could be a bit fuzzy and out of context till then (and likely a while longer till I get there).

I'm working with an in-progress feathers-next project using f-a-m that is ready to convert to a-l-m. The project is intentionally underdeveloped and weird in places considering where it came from (a fork), where the concept is going (a larger established private project), and what else I thought it could be: a minimal proof-of-concept playground for local user auth basics using feathers + a-l-m + next.js + redux. With clean commits, it may be an example reference for f-a-m → a-l-m conversion (or not, considering a-l-m ongoing dev) and I've had thoughts about writing an article for it.

One thing I encountered with my initial implementation with f-a-m that I'm wondering if there's a recommended solution with a-l-m, is how to independently verify user communication channels to avoid sending future communications to unverified channels. For example, if a user's email was verified but their SMS was not, don't send a password reset (or any communications) by SMS until/unless SMS has been verified – or vice versa. Maybe this is already covered? MFA is essentially self-verifying since it's typically verified from user input in the process of enabling it for an account (to ensure a user has it set up properly on their end). There's user.isVerified which seems to be connected to user.email and maybe that's related to feathersjs/authentication use of email vs username (by default), if I'm understanding that correctly that email is a core aspect even if I wanted to not use it. Verified user vs verified comm happens to both use "verified", but may not be same idea... So perhaps what I'm seeking, if not already covered, is in addition to vs a replacement for clean/easy/integrated way for something like user.isCommVerified['email'], user.isCommVerified['sms'], user.isCommVerified['someOtherComm'] and user.isVerified might relate to one or more comm channels having been verified. I could be overthinking in my desire to future-proof... not sure how many communication channels I may want to verify, the gist is to verify them all initially before sending messages to them afterwards.

[eddyystop]

Neither f-a-m nor a-l-m have the concept of authenticating a communication channel, let alone multiple ones. I see the use for these concepts but introducting it would take a significant effort which I'm frankly not willing to undertake under the (increasingly broken) OS model.

As an aside, neither f-a-m nor a-l-m are email centric. They are just as happy using the phone#. However all articles and discussions have been email-centric which leads to this impression.

[eddyystop]

https://www.troyhunt.com/everything-you-ever-wanted-to-know/