My application is linked with firebase database and authentication.
When a user creates an account, the only requirements for the password are for it to be 6 characters. Is there anyway I can make the password more complex, such as make them have a capital letter and a number.
Can I do this from firebase directly, or do I need to do this from my code?
There is no way to configure Firebase Authentication's rules for password strength.
Also see
Password Requirements when making an account with firrebase
Firebase Password Validation allowed regex.
You can (and should ) restrict it from your code. But you can't prevent malicious users from bypassing this by calling the API directly.
If the password strength is a hard requirement for your app, consider implementing custom authentication. This example of custom username (instead of email) and password authentication might be helpful.
Use this function. It includes range 6-15 i.e. minimum 6 and maximum 15 characters.One Capital letter , One number respectively.
func isValidPasswordString(pwdStr:String) -> Bool {
let pwdRegEx = "(?:(?:(?=.*?[0-9])(?=.*?[-!##$%&*ˆ+=_])|(?:(?=.*?[0-9])|(?=.*?[A-Z])|(?=.*?[-!##$%&*ˆ+=_])))|(?=.*?[a-z])(?=.*?[0-9])(?=.*?[-!##$%&*ˆ+=_]))[A-Za-z0-9-!##$%&*ˆ+=_]{6,15}"
let pwdTest = NSPredicate(format:"SELF MATCHES %#", pwdRegEx)
return pwdTest.evaluate(with: pwdStr)
}
This func will return true for valid password string
Related
Context
I've build a RESTful API server in Actix-Web with Rust that's hosted on a Heroku paid plan. It has n amount of publicly available endpoints to access content, alongside 3 strictly admin-only endpoints (for creating, editing, and deleting public content).
I am the only developer who'd ever need to access the admin-only endpoints - and infrequently at that. Several random users will be using the publicly available endpoints daily.
Normally, I'd implement an authentication/authorization strategy akin to this using JWTs (but obviously in Rust for my case). However, the added complexity that comes with this "more common" solution seems overkill for my simple use-case.
My theorized solution
Could I add a username and password field to the .env file in my project like so in order to match against a username and password passed in the admin-only handler functions?
... OTHER KEYS ...
USERNAME = my_really_long_random_username
PASSWORD = my_really_long_random_password
At first glance I'm storing passwords in plain text... but, there's only 1 and it's in my .env file, which is private by default.
All I'd do for the admin-only routes then is this (pseudo-code):
pub fn router_handler(passed_data) -> HttpResponse {
if passed_data.username == env.username && passed_data.password == env.password {
// CONSIDER THEM ADMIN
} else {
// BLOCK THEM AS THEY'RE NOT AUTHENTICATED
}
}
What I've tried
I have yet to try this strategy, but I'm curious about your opinions on it.
Question
Is my theorized solution secure? Does it seem reasonable given my use-case?
Response to question: jthulhu - is this what I do?
So, my .env file should look something like this:
... OTHER KEYS ...
USERNAME = a98ysnrn938qwyanr9c8yQden
PASSWORD = aosdf83h282huciquhr8291h91
where both of those hashes are the results of running my pre-determined username and password through my to_hash function which I added below (likely using a lib like this).
Then, my handler should be like this (psuedo-code):
pub fn router_handler(passed_data) -> HttpResponse {
if to_hash(passed_data.username) == env.username && to_hash(passed_data.password) == env.password {
// CONSIDER THEM ADMIN
} else {
// BLOCK THEM AS THEY'RE NOT AUTHENTICATED
}
}
You should never store passwords in plain text in a server, because if someones breaks in your server, and can read that file, they now have access to everything (whereas they might previously not). Not only that, but most people tend to reuse passwords, so storing one password in plain text means exposing several services where that password is used.
Instead, you should hash the passwords and store the hash. To perform a login, check if the hash of the given password corresponds to the one stored. This mechanism can be used with files or with databases alike, and is pretty much independent on how you actually store the hashes.
First of all im Using TYPO3 Version 8.7.
The current problem i'm facing regards authentication of FrontendUser (fe_user) stored on a given page (in this case pid 168).
Apparently i'm trying to authenticate user with given credentials sent by a mobile application. I'm able to parse the user data and perform an authentication:
// plain-text password
$password = 'XXX';
// salted user password hash
$saltedPassword = 'YYY';
// keeps status if plain-text password matches given salted user password hash
$success = FALSE;
if (\TYPO3\CMS\Saltedpasswords\Utility\SaltedPasswordsUtility::isUsageEnabled('FE')) {
$objSalt = \TYPO3\CMS\Saltedpasswords\Salt\SaltFactory::getSaltingInstance($saltedPassword);
if (is_object($objSalt)) {
$success = $objSalt->checkPassword($password, $saltedPassword);
}
}
While debugging this code snippet, i recognized the password sent by the user via Request, which gets encrypted with the given Salt algorithm change every time i retry this request. I'm not sure how to get a correct authentication, if the password changes constantly.
The $objSalt object contains the right Hashing Method($pbkdf2-sha256$25000), the password stored in the Database starts with the same prefix, but the actual payload is different.
So What is the exact problem or whats the thing i'm missing in the above code to complete the authentication?
Thanks for your help
BR,
Martin
the password sent by the user via Request, which gets encrypted with the given Salt algorithm change every time i retry this request
Yes, that because the salt is changed every time.
You should retrieve the salting instance with:
$instance = \TYPO3\CMS\Saltedpasswords\Salt\SaltFactory::getSaltingInstance($user['password']);
So any one who has used perl dancer knows that to authenticate a user on login you can call authenticate_user
authenticate_user(
params->{username}, params->{password}
);
This is part of the Auth::Extensible plugin.
To me it looks like it encourages the use of storing passwords in plain text! Sure you can hash the password first then make sure the stored password is the same hash but this seems to be more of a work around and i found isn't guaranteed to work. I have only got this to work using sha1 which shouldn't be used. I want to use Bcrypt but the passphrase simply wont match. Possibly odd characters not matching i'm not sure.
The thing is using the dancer Passphrase plugin i can already validate the username and password without even needing to rely on authenticate_user to verify them. But for the dancer framework to consider the user logged in you still have to call authenticate_user which must be passed the password.
I'm completely stuck. I'm curious how other people have managed to use proper password management in dancer2?
Firstly, I'll echo the "you almost certainly don't need to be using authenticate_user()" comments. The plugin can handle all that for you.
However, "it doesn't hash it" is wrong; here's how it works. The
authenticate_user keyword loops through all auth realms configured, and for
each one, asks that provider's authenticate_user() method to see if it accepts
the username and password. The Database provider (and the others) fetch the
record from the DB, and use $self->match_password() (which comes from the
Provider role) to validate it; that code checks if the stored password from
the database starts with {scheme} and if so, uses
Crypt::SaltedHash->validate to validate that the user-supplied password (in
plain text, as it's just come in over the wire) matches the stored, hashed
passsword ($correct in the code below is the stored password):
if ( $correct =~ /^{.+}/ ) {
# Looks like a crypted password starting with the scheme, so try to
# validate it with Crypt::SaltedHash:
return Crypt::SaltedHash->validate( $correct, $given );
}
So, yes, if your stored password in the database is hashed, then it will match
it if the password supplied matches that hash.
For an example of what a stored hashed password should look like, here's
the output of the bundled generate-crypted-password utility:
[davidp#supernova:~]$ generate-crypted-password
Enter plain-text password ?> hunter2
Result: {SSHA}z9llSLkkAXENw8FerEchzRxABeuJ6OPs
See the Crypt::SaltedHash doco for details on which algorhythms are
supported by it, and the format it uses (which "comes from RFC-3112 and
is extended by the use of different digital algorithms").
Do bear in mind that the code behind authenticate_user is exactly what's used
under the hood for you.
For an example of just letting the plugin do the work for you, consider:
get '/secret' => require_login sub {
my $user = logged_in_user();
return "Hi, $user->{username}, let me tell you a secret";
};
... that's it. The require_login means that the plugin will check
if the user is logged in, and if not, redirect them to the login page
to log in. You don't need to call authenticate_user yourself, you
don't need to set any session variables or anything. logged_in_user()
will return a hashref of information about the logged in user (and because
the route code has require_login, there's guaranteed to be one at this
point, so you don't need to check).
If you need to check they have a suitable role, instead of just that they
are logged in, then look at require_role in the documentation instead.
In the documentation for Dancer2::Plugin::Auth::Extensible, the description for authenticate_user() says:
Usually you'll want to let the built-in login handling code deal with authenticating users, but in case you need to do it yourself, this keyword accepts a username and password ...
Which strongly implies to me that you shouldn't be calling this function at all unless you're doing something particularly clever.
I haven't used this module myself, but it seems to me that all the hashing and encryption stuff should be handled by one of the authentication providers and if there's not one that covers the case you use, then you can write one yourself.
Whenever I need to store secure passwords for a Dancer app, I reach for Dancer2::Plugin::Passphrase. I wonder if I should consider writing an Auth::Extensible style authentication provider for it.
Based on the Google Developers site, it looks like apps can store emails and passwords into Smart Lock. Is there a way to also store phone numbers in Smart Lock? Very important for messaging apps.
Yes, you can store any string as the identifier when constructing a credential object, including phone numbers and general usernames, not just email addresses. Ensure to store any phone number in a format your app understands and can use when you retreive it from the API; identifiers will not be normalized in any way.
Example on Android (similar for web):
String phoneNumber = "+1 (650) 253-0000";
Credential credential = new Credential.Builder(phoneNumber)
.setPassword(password)
.build();
Auth.CredentialsApi.save(apiClient, credential).setResultCallback(new ResultCallback() {
public void onResult(Result result) {
Status status = result.getStatus();
if (status.isSuccess()) {
Log.d(TAG, "SAVE: OK");
// updates to existing credentials will succeed immediately
} else if (status.hasResolution()) {
// confirmation is required to save a new phone number
status.startResolutionForResult(this, RC_SAVE);
...
Note that if your phone number-based accounts don't have passwords, you could set the "account type" to your own URL instead of password for the credentials (i.e. .setAccountType(YOUR_URL) when building a credential).
See the developer docs for saving and retrieving credentials with Smart Lock for more information, and leave any follow-up questions in the comments.
I'm coding a web app using Laravel 4.1 and Postgresql as database.
The db is case sensitive, but i'd like to make it case insensitive because, i.e., when a user is logging he should be able to access using upper case or lower case email address (like in every other website). However the column for the hash of the password must be case sensitive because the encryption method i use generates case sensitive strings.
I'm using Eloquen ORM of Laravel so i don't write queries directly.
How can i solve this problem?
Thanks in advance!
A bit late, but this is pretty simple. Just use the "ILIKE" operator, e.g.
User::where("email", "ILIKE", $email)->get();
I had this exact problem- my solution was to pretend to be case-insensitive:
1) add one line in the relevant methods to make the entered email value lowercase
2) did a replacement in the database so that emails were lowercase
3) made sure that new emails come in as lowercase
Details:
1) The relevant methods* are core laravel code, so you override them with a new version that replaces the email value after validating the request:
$request['email'] = Str::lower($request['email']);
log in flow: postLogin function from AuthenticatesUsers trail, I added to AuthController.php postLogin
password reset flow: postEmail and postReset functions from ResetsPassword trail, I added them in PasswordController.php
2) update users set email = lower(email);
3) For me this is easy because I create all users myself (my site is just for family)- but you'd do something similar in the auth flow
Hope this helps!