We have a dataset of usernames and passwords that we'd like to migrate to FusionAuth.
According to the tutorial, we can write a password encryptor to implement our hashing logic, so we don't have to ask users to reset their passwords.
However, we'd like to benefit from the available encryptors for new users or when migrated users reset their passwords.
It's my understanding we can't convert the salted hash passwords to other encryptors.
Is there a strategy for that?
Thanks!
If I understand correctly, you want to migrate users with an existing hash, but have the option to upgrade that hash at runtime without any user impact?
This is possible, you import the hash as you have it, and then configure FusionAuth to upgrade the hash at next login to the configured default.
When you enable 'Re-hash on login' if the user's hash does not match the configured scheme and factor, FusionAuth will upgrade the hash and the user will not be affected.
Find this setting is the UI, see Settings --> System --> Passwords.
Related
This question already has an answer here:
Automatic Login from one web site to Moodle web site?
(1 answer)
Closed last year.
I have an user details stored in my web site database and Moodle database. I logged my website with that credentials , Moodle also auto login with that credentials is there any way? Or any Code is available?
If you're handling credentials correctly (and Moodle does), you DO NOT STORE THE ACTUAL PASSWORD! Instead, you store a salted hash of the password.
When someone tries to log in, you salt and hash the attempted password using the same salt and hashing algorithm. This will give you the same result as the value in the database, and so instead of comparing passwords directly you now compare hash values. In this way your users are protected from having their passwords leaked if someone breaches your application.
If you're not doing it this way on your own site, you're doing it WRONG and need to fix it ASAP. This is big deal!
Here's the thing: the two web sites aren't necessarily using the same hashing algorithm, and certainly aren't using the same salt. Therefore the user credentials you have saved for your web site are NOT the same credentials saved in Moodle, even if all the users have the same password.
But what you're really asking about is SSO (single-sign-on). There are (safer!) ways to support this. SAML, CAS, Shibboleth, and OAuth come to mind, and Moodle definitely supports these. You can also have Shared (as opposed to Single) Sign-On, where both your app and Moodle use a third party such as AD or LDAP for identity verification, so the username/password credentials are the same but you still have to sign into both applications separately.
Unfortunately, you will need to build this into your own app, as well, and perhaps even add an additional authentication portal server to your organization to act as the trusted intermediary between each of these applications. There are a number or products you can use, including some that are open source or may already be included with other licensing, so you don't have to start from scratch or necessarily make an expensive purchase here.
The good news here is these products generally also put you into a good position to start supporting Multi-Factor Authentication, which is also an important feature to provide.
I recently started getting notifications about the GitHub deprecation of basic authentication using a password to Git - see their blog post https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/.
In this post, they say the following:
For developers, if you are using a password to authenticate Git operations with GitHub.com today, you must begin using a personal access token over HTTPS (recommended) or SSH key by August 13, 2021, to avoid disruption.
A short while ago, I started using SSH keys on some of the machines I use anyway to avoid entering my password regularly or storing it unencrypted with credential helper. However, as per above, they say personal access tokens are "recommended".
What I would like to know is what are the key differences between each of these methods? This is to get some insight into why tokens are "recommended" and whether it is worth switching to this method of authentication.
From the blog post you linked, I can see at least one benefit of tokens over SSH keys: while tokens and SSH keys both share the Unique, Revocable, and Random benefits quoted in the blog post below, tokens are also Limited in comparison to SSH keys in that they come with their own scoped permissions baked in:
While SSH keys can be read-only or read-write enabled, or scoped to specific repositories, personal access tokens do have an edge in terms of their finer-grained permissions model in comparison. This is likely why GitHub recommends tokens over SSH keys.
Tokens offer a number of security benefits over password-based
authentication:
Unique – tokens are specific to GitHub and can be generated per use or
per device
Revocable – tokens can can be individually revoked at any
time without needing to update unaffected credentials
Limited – tokens
can be narrowly scoped to allow only the access necessary for the use
case
Random – tokens are not subject to the types of dictionary or
brute force attempts that simpler passwords that you need to remember
or enter regularly might be
I want to write a library for my media files. Since I am using a few SAMBA-shares i was wondering how I should save the passwords, since I need them to access the share. Is there any other possibility to store them than just plain text?
I am using postgresql for the data. The end-product will be a web app.
The difference to other password saving questions is, that i need to send the password to other services. That's the reason why I can't save hashes.
If you store the NT hash you should still be able to NTLM authenticate to Samba. This isn't a bulletproof solution since the NT hash is as good as the password itself to servers that accept NTLM authentication, but assuming that your Samba server is well-protected on a private network it's still an improvement. Among other things, it makes it less likely that someone stealing your password database can use the contents to compromise users' accounts on other systems where they may use the same password.
I have a system that needs logins, but who i'm building it for is requiring the transmission of the passwords during login to be very secure (even using SSL). So i'm using a variant of the Digest access authentication to transmit login requests. The only problem i'm having now is how to store the passwords on the database (in a secure salted hash preferably) so they can be used with the digest request, and the password at no point is in an nonhashed format, except on the clients browser for a few seconds.
So, in a nutshell, how can I store passwords securely but allow for a digest (with a different and ever changing nonce to the database's salt) to authenticate?
As I understand it, this mechanism sends something like:
hash(nonce + hash(password + salt))
So on the server, you just need to store hash(password + salt) and salt.
You may want to take a look at the source code of this Perl module; it manages *nix accounts.
Under normal circumstances to authenticate a user in AD, one sends AD the user's clear text password (using SSL, hopefully). For reasons that are out of my control, I only have an MD5 hash of the user's password. Is it possible to configure AD to authenticate users using this hash instead of the original password?
Thank you
After much investigation it is now apparent that AD will not support the scenario. AD does not expose its internal hash externally, and besides, it doesn't use MD5 to hash passwords. It uses something stronger.