For an app im making using Meteor i have the function to add users on the client app however if i just call the Accounts.createUser it automatically logs in to the new users' account. To get around this i am currently calling a server side method and just passing the data in the Meteor.call() below. I am pretty sure that this passes the password as plain text to the server which is bad.
Is there any way for me to make sure the data is securely sent to the server method without it automatically logging the user in?
Meteor.call('serverCreateUser', username, password, phone, email, admin)
I am pretty sure that this passes the password as plain text to the server which is bad.
Using a standard Meteor method, yes. This is why you should always use https in production!
There is, however a different approach you can implement. You can actually create a user, without providing a password, then nobody can login with this account. You then send an enrollment email to this user, requiring the user to set an initial password, which is then hashed, before being sent over the wires:
Meteor.methods({
'serverCreateUser' (username, phone, email) {
// server should consider based on server-only rules, whether
// a user will be an admin!
const userId = Accounts.createUser({ username, email })
// set profile fields
Meteor.users.update(userId, { $set: { phone })
// send enrollment mail
Accounts.sendEnrollmentEmail(userId)
// return new user id
return userId
}
})
When on the client the user sets the initial password it will use Accounts.resetPassword.
Note, that this still requires https, because a hashed password is still not an encrypted password.
Related
I used firebase auth email/password sign in with the isEmailVerified property. isEmailVerified set to true allows the user to get through to their logged in home page. isEmailVerified set to false displays a screen telling the user to verify their email before they can get through. Two problems here:
If a user creates an account with an email that is not theirs (I know email link sign up solves this, but looking for a solution via the email/password auth route), is there a way to discard of that account when the user doesn't verify their email within a certain amount of time? Trying to avoid excess false/mistake accounts.
Lets say the user does use a correct email to sign up and they are through to their account after email verification, but they want to change their email at a later date (say via account settings using the updateEmail method, for example), then the user changing their email to an incorrect email would essentially make the user lose their account. This is similar to problem #1, but worse, because in problem #1, some sort of solution that discards accounts with isEmailedVerified = false would discard an brand new account with no history, BUT with this problem, that same solution would discard a used account with history attached to it. This is because the user would then have to login with the new incorrect email on their account, but isEmailVerified would be set to false, but they can never correct it since they don't have access to the new email.
These 2 problems happen because in firebase auth accounts are created before the sendEmailVerification is sent and isEmailVerified is set to true. Any solution?
I know email link sign up solves problem #1 since account creation and email verification happens together on initial sign up, but looking for a solution via the email/password route. I don't think email link sign up solves problem #2.
You can have a function that checks your users list periodically and finds & removes users whose account has not been approved yet (after x days)
// running periodically & using firebase admin SDK
getAuth()
.getUser(uid)
.then((userRecord) => {
console.log(userRecord)
// if email is not verified & sign up date > x => delete user
})
.catch((error) => {
console.log('Error fetching user data:', error);
});
Here user Record will contain information about user's email verification.
Problem 2. You should allow another sign in method, i.e., phone, etc. so that if they lose the email, they can still verify their identify in another way. Otherwise your issue is a logical issue.
But if you want to keep it with just email, then you should not update their email right away, rather send verification and on the verification process you would also update their email. The logic needs to be handled in the backend.
I am new to Django and I am working on the user authentication part. I used the Django provided User model, and use auth() and login() method when the user login.
I have a question about the password security and hope have some discussion here.
When the auth() function hashed the raw password and then compares the username and the hashed password. That means the front end needs to send the password in raw data. (Otherwise, it will be hashed twice).
Is it not safe to send the password in raw data? If I want to hash the password in the frontend then send the request to Django, what can I do in this case?
It's OK if you pass password in post request
But for more security, you can encrypt data ...
I created a desktop application that talks to Graph API (Beta).
In the development version, I deployed it on the application I created myself on Azure AD. As one of the requirements is not to show login dialog when using the application, I decided to go with UsernamePasswordProvider, which I provide the user name and password of my account and everything works fine (I didn't put client secret in my application).
When I'm about to deploy it on customer's network, I asked the admin and he provides me the service user name, password, tenant ID, client ID, and a client secret.
I tried using Postman to check if I can get an access token from those info and I can only if I provide the client secret along with user name and password.
When I'm back to the code, UsernamePasswordProvider's constructor accepts IPublicClientApplication which has no option to create the application with client secret.
I understand that there is a reason behind as the secret can be easily stolen if the application got decompiled but, if I'm (in fact, my client) not serious about this, is there any way to initialize the GraphClient by putting user name, password, and client secret together for authentication?
Important, the Username / Password flow is not recommended because your application asking a user for their password is not secure. For more information about this problem, see this article.
If you still would like to use it, you could put username and password of that user in Key Vault and fetch those in your code.
string keyVaultName = Environment.GetEnvironmentVariable("KEY_VAULT_NAME");
var kvUri = "https://" + keyVaultName + ".vault.azure.net";
var client = new SecretClient(new Uri(kvUri), new DefaultAzureCredential());
var secret = client.GetSecret(secretName); // get username or password here
I recommend you to use ClientCredentialsProvider, it enables service applications to run without user interaction.
I'm new to nodejs, and I'm trying to create and REST_API server, the thing is:
1- I have user registration and login currently working using passport
What i am a bit confuse is:
When a user get access to they're dashboard, i want to have and button that says (Generate your API Key). Then the user will use this key in header requests to my REST_API. That's where i'm not understanding, what should i use to get the above flow?
I tried using JWT to generate a token, but that was only creating the token when user login, and i don't want the user to have to login everytime.
Here's my login route:
app.post('/api/login', passport.authenticate('local-login'), function (req, res) {
res.json({ message: req.authInfo, user_id: req.user.id, user_email: req.user.local.email, loggedin: true });
});
If there's something else i have to provide, please ask ok?
Thanks!
When a user get access to they're dashboard...
Make a post request to an endpoint, pass the userid, that way you will know which user the key it’s been generated . Generate the key and return it. You can store it in cache or session to use during the session
i don't want the user to have to login overtime...
If you don’t want to make your user login everytime. You could store user and pass in browser cache(encrypt the pass). so, when user heads to the app you have to check if user and pass are in cache. if so, log the user in.
Here is the approach that I follow.
I secure the routes for my API like this:
Route::group(array('prefix' => '/api/v1'), function () {
Route::get('dashboard', array('before' => 'basic.once', function () {
return 'Dashboard';
}));
});
I am planning to use basic auth over an SSL connection.
I have to send username and password to the with every request.
I understand that I need to store some user details on the client side (angular/browser) so that the user logs in once and is allowed to access protected routes until his session is valid.
What I don't understand is what user information do I store at the client end and how?
The API will be used for building mobile apps in future.
What is the simplest thing I can do to achieve this?
The simplest way is that when a user register (or you create a user), you add an extra field not just the standard credentials (username, password), this extra field can be token what you'll generate when you create the user, after that when your user logs in you send back to him this unique token, and at client side (angularJS) you can store this token for example in session storage, and after this you need to send this token with every API call. To simplify the back-end you can make a filter to test the token and log in the user. This will be important if you want to use your application on mobile devices where aren't cookies, so you will log in the users with every call.