I have an existing site that has user passwords hashed using sha1 hashing algorithm. I need to port those users (and passwords) to the new Meteor site.
Is this possible?
i recently encountered a similiar problem and just migrated the accounts and had users reset their passwords. you can then use the built standard accounts methods to handle login+reset functions.
login method call:
Meteor.loginWithPassword(email, password, function(err){
if (err){
if(err.reason === "User has no password set"){
Session.set('loginErrorMessage', 'you have been migrated... reset your password...');
//your template does something with this to push user to reset their password
}
}else{
//normal login
}
});
can only really do this if you have a custom login form, you could possibly just lightly customize the accounts-ui package if desired
this approach has worked pretty well for my app so far, users just have to follow the password reset procedure and they are good to go
Related
I have my own Users page in my application where user Admin can create a new user.
I do not want to let the user sign up by himself, but have the admin of the system add this user.
What do you think the flow for that should be ?
I thought about:
create a new user with username and temp password in the users page.
The user gets an email and presses a link to confirm the email.
The user goes to the login screen of my application and inserts the username and temp password.
the login page changes to Change password so the user will insert the password and confirm the password for him.
when pressing login the user logins to the system.
I cannot find a best practice for adding a new user from a built-in users page in the app.
Do you think my flow is reasonable?
Do you have any code that I can use for that?
This is pretty close to the flow which Cognito has for admin-created users by default when using the Amplify UI Authenticator component. The only difference is that the temporary password is sent to the user via email, so the admin never needs to see it.
To achieve this, you need to use the AdminCreateUser action. The way you do this will vary depending on the library you're using to communicate with Cognito. If it's Python, you can use boto3. If it's JS, you can use the AWS JS SDK. (Sample code in this GitHub comment.)
It's not required to use Amplify UI, you could write all the pages yourself. But it works well with very little effort and looks quite professional. So it should be the first thing you try. Here's another answer providing sample code for React.
Is there a way to disable or enable sign ups for a specific application which is independent of the “Disable Sign Ups”-toggle in the dashboard for login with passwordless email (Authentication/Passwordless/Email)?
Only partly.
It's possible via Pre-User-Registration Hook and/or or Rule with some caveats.
Pre-User-Registration Hooks :
https://auth0.com/docs/customize/hooks/extensibility-points/pre-user-registration
Something like this:
module.exports = function (user, context, cb) {
return cb(new PreUserRegistrationError('Denied user registration in Pre-User Registration Hook', 'You are not allowed to register.'));
}
};
Here you can just fail the registration at all times.
Problem with Hooks is that that the Pre-User-Registration Hook does not trigger for social connections / federation, only Database Connections and Passwordless.
Alternatively via Rule:
https://auth0.com/docs/customize/rules
This will always work, but the downside is that the user gets created in Auth0, they will just not be able to further proceed.
In the Rule you basically check the number of logins, if it's 0, you know that it's a new user, and block the login that follows right after user creation (signup) as well as any other time.
Example rule:
https://auth0.com/rules/disable-social-signup
Related earlier answer of mine regarding this, in the Auth0 forum:
https://community.auth0.com/t/disable-signup-from-auth0-ui-and-enable-social-login/29227/2
I just figured out I can create another 'Tenant' (from the dashboard) with a different setting for Sign Up from the dashboard :-)
You could implement a custom Universal Login SPA for sign-up/in that only allows users to sign-in. Pre-registration hook to safeguard against people bypassing the UX.
I want to apply gun.user in my project.
When I store the user in sessionStorage using user.recall(opt),
This code in sea.js stores password in tmp without encryption.
Is it okay? or..
Should I encrypt password before calling .auth?
Here is my code.
jq('#up').on('click', (e) => {
let form = check();
if(!form){ return }
S.user.create(form.alias, form.pass, (ack) => {
if(ack.err){ return S.tell(ack.err) }
check.up = true;
S.user.auth(form.alias, form.pass, logined);
});
});
jq('#in').on('click', (e) => {
let form = check();
if(!form){ return }
S.user.auth(form.alias, form.pass, logined);
});
let logined = (ack) =>{
if(ack.err){ return S.tell(ack.err) }
S.user.recall({sessionStorage: true});
}
+
I found the document about user.create().
Passphrase that will be extended with PBKDF2 to make it a secure way
to login.
However, there is plane text in my session storage.
gun version is 0.2019.515.
#huhsame , great concern! (And btw, incredible GUN AR/VR demos on your twitter!)
Browsers require domain-based security which sadly limits P2P security.
Unfortunately, sessionStorage is the safest best browser option:
Credentials are not shared with servers (like cookies do).
It keeps a user logged in on refresh.
It deletes the credentials if you close the tabs.
Between page loads, encrypting the password is a good idea but the problem is, to keep the user logged in, the decryption key also has to be stored. :(
Storing credentials in localStorage is unsafe, which is why sessionStorage is better.
Warning! Unless you use a Browser Extension (below) or Browsers adopt better solutions, an XSS leak can compromise credentials from sessionStorage - but even if you disable it, credentials can be pulled from in-memory without an Extension to protect accounts.
PBKDF2 is used during the login process, not session management - again, it could be used there as well, but has the same limitations as above.
Even sessionStorage does not work well for keeping users logged in.
As a result, you should consider other solutions. I've written more about other options here:
Keeping a Gun DB user authenticated during a session
Better Security
For the best security, users would sadly need to install a browser extension, like our http://party.lol tool, until Browsers adopt this type of security natively, or offer better user-centric session management.
I want to implement the app in worklight using JsonStore protection i want to store password based on logined user and add those password to options in WL.JSONStore.init(collections,options). The rest of the details in data object data={};
and how do i extract the password saved WL.JSONStore.init(collections,options) options object for making api calls for rest of the functions?
My take on the question:
Storing the password in the device is indeed not a good practice to follow.
There is also the additional question of where the username and password are coming from originally? When does the sign-up (rather than log-in) happens? This is IMO crucial information.
In one of my applications I have initialized a JSONStore and encrypted it using the user's password and in the collection I saved the username.
This way, the next time the user tries to open the JSONStore (read: "to log-in"), it will try to do so with the inputted password. If this step is successful, it will then compare the inputted username with the stored username. If this step is successful as well, valid login credentials can be assumed.
var collections = {
userCredentials : {
searchFields : {
username: 'string'
}
}
};
var username, password;
username = $("#username").val();
password = $"("#password").val();
WL.JSONStore.init(collections, {password:password})
// first step is successful
.then(function() {
return WL.JSONStore.get("myCollectionName").find({username:username});
})
// second step is successful
.then(function(searchResult) {
if (searchResult[0].json.username == username) {
// valid login.
}
})
.fail(function() {
alert ("Invalid credentials, try again.);
})
Note that the above code is a bit abstract and "generic", and you will need to handle all sort of edge cases.
I highly recommend to thoroughly read all of the JSONStore documentation and training modules.
You have two options (though I am not a security expert):
Ask to user that uses the app (and therefore the JSONStore) to enter the password each time you open the app and then in the WL.JSONStore.init method check the password (if the password is correct, the store will open, otherwise, the method will fail).
Store the password in a secure storage - Keychains. For iOS see this link. For Android, I think this is the equivalent link.
So, the first time the user opens the app, you store the password and each time the user opens the app, you retrieve the password and pass it to WL JSONStore. If the user wants to update the password (e.g. you have security policy to follow), you have to update the password in the Keychain.
Of course, if you go hybrid, you will need some sort of Cordova plugin that add, reads, updates, resets the password in the keychain so you can make these actions from JavaScript.
Hope it helps!
Hi StackOverflow Community!
I am working at BOX API . Everything is fine,but I want to change the Authentication behavior.
Authentication process first go to box website for ACCOUNT HOLDER Authentication. Is it possible to auto Authenticate using username/password and users view ACCOUNT HOLDER files directly?
I am looking forward.
Similar question asked here with a solution involving renewing bearer and access tokens. Only restriction is that the renewal needs to occur at least once every 14 days. I hope this is a workable solution for you.
It looks like this isn't possible. The Box API uses OAuth 2.0 authentication, which explicitly requires you to redirect the user to the Box website so that they can "allow" access to their account. See http://developers.box.com/oauth/
Which SDK are you using iOS, Windows, Ruby, other? It is possible to auto-login basically it would involve having the user configure their username and password somewhere. Then if you take those stored values and using javascript calls you can input the username and password into the appropriate fields and then submit the form. Depending on the api you'll be presented with a different login screen.
Disclaimer Box changes their login screen frequently and seems really buggy so I wouldn't recommend this route but if you want to do it any way the javascript will look something like:
var username = "user1";
var password = "superSecretPassword";
document.getElementById('login').value = 'username';
document.getElementById('password').value = 'password';
document.forms[0].submit();