I have an application using Parse to store server side data. I apply rules to the entry of a password using a regex successfully. However when I use Parse's PFUser.requestPasswordResetForEmailInBackground function the user is emailed a password reset URL which allows any password to be entered in the reset. The problem is that when the user returns to log into the application with their new password it may not conform to the rules set in the regex. How can I enforce password rules in Parse?
Related
I have default auth implemented in Laravel 7 and works like a charm.
However, I have a very peculiar requirement wherein, the password shouldn't even travel in plain text although SSL is implemented on network.
One way would be to handle it via javascript on login page wherein I encrypt the value of password and send the same to server and then decrypt the same in php before handing it to laravel attemptLogin method.
However, I am not so sure about this approach.
Any help would be awesome.
Solution:
On client side, used crypt.js/aes.min.js and encrypted the password using a key and iv.
In login controller, overrode credentials method and decrypted using openssl_decrypt before passing on to hash check.
This is already discussed on this answer:
It is standard practice to send "plaintext" passwords over HTTPS. The
passwords are ultimately not plaintext, since the client-server
communication is encrypted as per TLS.
And this one:
If you hash on the client side, the hashed password becomes the actual
password (with the hashing algorithm being nothing more than a means
to convert a user-held mnemonic to the actual password).
This means that you will be storing the full "plain-text" password
(the hash) in the database, and you will have lost all benefit of
hashing in the first place.
You may also read this answer for more security options.
I solved it as below:
On client side, used crypt.js/aes.min.js and encrypted the password using a key and iv.
In login controller, overrode credentials method and decrypted using openssl_decrypt before passing on to hash check.
I'm using Laravel 7.x and sanctum. Logins are working and I would like to create a Forgot Password option from my SPA application.
I'm struggling with the basics as most of the examples in the documentation rely on the auth scaffolding. So far I've managed to get the following:
I have a controller class called ForgotPasswordController with a method called reset that receives the email to be reset via POST.
I've created a object: $user = User::where('email', $email)->get()->first();
At this point I'm too unfamiliar with the architecture to know where to go next, whether it's the Password facade, I see some additional classes in the Illuminat\Auth\Password namespace. My goal is to create an expiring token, email it to the user via the default email config (I know how to send the email / design the template) and then be able to make the webservice call that will allow the password to be resolved.
Here's what I think I know...
I've set CanResetPassword trait on my user models, which I believe are necessary to support the native methods for password reset
I believe the goal is to create a reset token keyed against the user email that expires after a period of time, then send that token appended to a url in an email (I don't know the architectural implications surrounding the generation of the token beyond the table row)
There's a Password facade with a sendResetLink method - but this
method can't work for spa applications because the base url of the
client app will be different, so I'm assuming something native will have to be re-written. In fact, calling this method will return an error of Route [password.reset] not defined.
I'm assuming I will need the password Facade, if so, what is the method to generate the token? Should I just email the link with the token appended or are there other architectural considerations to support the token expiration?
Apologies if my questions are flawed, I'm unclear on the architecture so I'm making assumptions.
Have you tried Laravel authentication? All authentication requirements have been moved to a package called laravel/ui.
By installing that package you can use Laravel authentication. It will take care of your registration, login, and forgot password processes.
This package will create some controllers for all those processes and those you need for forgot password are
ForgotPasswordController: will generate and send reset password links.
ResetPasswordController: will reset the password by getting user's email, new password, and reset password token.
But if you don't want to use the official Laravel package you should take these steps:
Show a "Request reset password form" to the user.
Validate the provided email by the user.
Generate a random reset password token and store it at DB (Need a table with at least two fields: email and token).
Send that token to the user(It's better if you send it as a URL parameter in the reset password link).
When the user navigated to the reset password page, ask for email again and validate the token by checking your DB table and matching the email and token.
Reset the password to whatever the user wants at this point.
Update: I use this piece of code for generating random tokens:
$email = 'user#email.com';
$token = \Illuminate\Support\Str::random(10);
while(\DB::table('reset_password_tokens')->where('token', $token)->exists()) {
$token = \Illuminate\Support\Str::random(10);
}
\DB::table('reset_password_tokens')->insert(compact('email', 'token'));
I am using spring security to authenticate a user. The user is authenticated by a third party and will already be authenticated when he reaches my application.
To implemented this, I have simulated a Authentication object.
I don't have any username and password and instead just have identifier. I check if this identifier is valid or not using my custom code.
My query is as follows:
Do I require a username and password to create a authentication object.
I have done without providing username and password and my application works fine.
I just want to ensure that I am using spring-security correctly.
Is there any impact of not putting username and password in Authentication object. I read below in AbstractUserDetailsAuthenticationProvider:
// Ensure we return the original credentials the user supplied,
// so subsequent attempts are successful even with encoded passwords.
I have also implemented a custom provider.
What does above comments means?
Is my approach correct?
The Authentication interface in Spring Security represents a token for carrying out validations against the configured security rules and the current call context. This interface has six methods of interest - getPrincipal, getCredentials, getDetails, getAuthorities, isAuthenticated and setAuthenticated.
Since you are authenticating users on your own, you should be mostly concerned with calling setAuthenticated(true) at an appropriate stage in the flow so that isAuthenticated starts returning true to indicate an authenticated user. Additionally, you may add GrantedAuthoritys to the Authentication for any role-based checks to work correctly.
However, it will be useful to make sure that getPrincipal (username in the case of form login) returns a unique value per user or per session. This will prevent the possibility of user sessions getting interchanged due to non-unique principal, which is used by the framework to identify users uniquely.
You may leave getCredentials and getDetails unimplemented. In fact, getCredentials (password in the case of form login) should be left unimplemented in your case because your application does not have the credentials used to actually authenticate the user; plus, it is a security risk to keep the credentials around after the user has been authenticated successfully.
I have a spring controller method which could be called in different scenarios. here is the example...
#RequestMapping("/resetpassword")
public ModelAndView resetpassword( #Valid #ModelAttribute("resetpasswordForm") ResetPawdFormForm resetPawdFormForm, ModelAndView modelAndView){
... this method could be executed in 3 different scenarios....
using the hyper link coming from the user reset password link sent to user email..
eg: localhost/myApp/login/resetpassword//
Here I can authenticate userID and activationSecretCode in DB and let user reset password
user can click on resetpassword link from user settings page.
eg: Since the user is already coming from user settings page, I can validate userSession and allow him to reset password
User can login for first time successfully, but are forced to reset password due to admin requirements for reset initial default password.
eg: in this user neither have session, nor passing any activationcode to validate.
login method validates userid/default password and redirects to resetpassword mapping(method=GET).
How can the system authenticate the user request and allow him to reset password?
One alternative for this is, to use flash attributes and set a authenticationKey as flash attributes...which could be verified in resetpassword method.
is there other way to implement this....
Note: I posted an issue in implementing this approach in
Post: Spring: How to pass Java objects during redirect while using ModelAttribute
Any help?
I think the best way to implement this is using three different action methods:
resetPassword (e-mails)
resetLoggedUserPassword (via settings)
changeDefaultPassword
They may even share the same view, but the behaviors are not equal, so I would avoid overloading the action responsibility.
EDIT: elaborating on your comment:
1) To secure the e-mail link, one way is to add a authentication token. The token can be as weak as a hashed user id plus some salt string, or as strong as a GUID with expiration time in a database table, generated whenever a user requests a password reset.
2) The settings way is not a problem, considering that the user is already logged in.
3) The temporary password action can be secured the same way as 1, or the same way as 2, if you put the user on the session. Logging in the user even with the default password status shouldn't be a concern if the code that verify the status of the account are inside a request filter.
I'm working on developing a page that pulls data down only via ajax:
http://itprojectguide.org/projectmatrix/itprojectguideprojectmatrix.html
the page currently pulls a status json data file.
To authenticate I'll be adding a preliminary signin (user name/password) and I'm thinking about doing the following to ensure a valid logged in user is present:
when signing in, send the user ID, and md5 hased password - the server will return a encrypted string containing User ID, signin date, level
I will pass this encrypted string to all pages, each page will send the string and page type to the server - the encrypted string will be validated to ensure valid user and that the user has signed in within the last 24 hours (based on the date). Data will be returned based on the user's level and the page that the user is on + any page specific data (say date range or company ID depending on the date)
Will the use of the encrypted User ID, signin date, level ensure proper security? I'm looking not to use cookies...is there a better way?
Part of this effort is to use ajax/json only interaction to retrieve data for each page instead of rendering it on the server..
Since you are rolling your own session management logic, you need to ensure the following:
The string returned by the server after authentication is not guessable. You might be encrypting it to prevent tampering, but you also have to account for replay and hijacking attacks. It is for this purpose that most session IDs are generated using PRNGs.
The string is protected during transmission. It depends on what value you (or rather your customers) assign to the data in the application. If the string can be snooped from the wire leading to significant business damage, you should look at HTTPS.
Sessions eventually should expire. The longer the session is active, the greater the chance for it to eventually be discovered.
You might consider using a One Time Password:
http://en.wikipedia.org/wiki/One-time_password
Also, if you can't run things over https you might piggyback on top of various OpenID providers' HTTPS, at least for the initial login to get the session cookie.