I have a web application which uses the UserInterface of Symfony for login and registering users.
And I have developed another application in Java which will have to communicate with my web application only if the user of the Java app is registered with the web application.
So in my Java application I'll ask a login and a password and I will send that to the web application.
But how can I check if it's the good user because I can't see the clear password of an user with UserInterface of Symfony?
I know it's for security reason, however in my special case I think that I have to decrypt my password user.
You can't.
First and foremost, because passwords and not encrypted. They go through a one-way cryptographic hashing function.
You can either verify the password against the hash in Symfony's side (by calling an endpoint and providing the credentials, and letting Symfony tell if they are OK or not)
Or, if your Java application has access to the same DB, replicate the verification on this side. (Something like this if you are using Bcrypt on Symfony; or something like this if you are using Argon2i).
Related
I am running into a situation where I am creating an application in symfony 6.2 to replace a legacy application. We are keeping all the users and I have a migration command that is moving the users from the legacy application to the new one. The problem I am running into has to do with the users’ passwords.
My preferred workflow would be:
User logs into new application
Form based authentication tests the credentials
Attempt to login to the legacy application API on credential test failure
Encode and store password in new application when the API login to the legacy application succeeds
I am stuck at the point of determining that the current user's credentials do not work on the new application and performing the API call to encode the password and store it.
Preferably I would like to be able to chain authenticators though I do not see that as an option.
I have created a custom authenticator that would perform the actions needed against the legacy API and on success encode and store the provided password to the user object.
I am wondering whether my custom authenticator has to handle the new application login form and security tasks?
Thanks in advance :)
I am developing rest apis in symfony application.
Right now my apis are used by my application only on frontend (ajax requests by Angularjs). In future I would like to expose same APIs to third party applications as well.
Also I will be having have Android, IPhone apps etc in future.
I have integrated FOSOAuthServerBundle, and have tried all grant type workflows. Its all working. But I am confused about can these be used by my application or are they for only 3rd party applications who like to integrate with my application ?
I understand how these workflow can be used by 3rd party apps. But really can't understand how can I authenticate my native application users ?
I want to know how to use this bundle to authenticate users on my website through rest apis from my frontend app ?
Currently I am usnig FOSUserBundle and form_long to authenticate user but I am changing frontend to use Angularjs and rest based. So ideally authentication should just work like form_login authentication but it should be rest based.
I did research on it and people suggest to use "Resource Owner Password Credentials" But it needs client secret to be exposed in javascript which may not be secure
It should work e.g. user submits username/password credentials like it works in case of form_login but instead of redirecting it should just return access_token.
Do I need to write my custome authentication provider which uses UsernamePasswordToken and firewall listener like OAuthListener which returns access_token ? Would that be secure to use?
The similiar question with some discussion here:
Symfony2 FOSOAuthServerBundle grant type password requires client secret
If you don't want to expose secret, use a proxy beetween your front-end angular code and actual OAuth server. Anyway, if you expose secret it still needs user credentials.
You can set allowed grant types to each OAuth client, so in case you create mobile apps, you'll want to generate a separate pair of client_id & client_secret for the app and for the front-end, with the only allowed grant type of "password" for the front-end app.
I am working on a CakePHP application which is part/sub another application that is developed in different technology ( ColdFusion ). Both apps have their own login functionality and they are required. Login functionality in CakePHP is by AUTH and ACL . Now the requirement is that when a user logged in parent app which is developed in ColdFusion user should directly go to protected pages/dashboard without logging in. I want a way to bypass the login functionality provided by Auth.
Thank you,
kiran
I want a way to bypass the login functionality provided by Auth.
You probably don't, you probably want to be able to log the user in automatically, which Auth supports.
You need to have some way for your PHP code to call ColdFusion to authenticate a user based on some shared secret (e.g. the login cookie for the ColdFusion part of the application) and then automatically log the user if they are authenticated.
So, I'm working with a really old system which uses a person's mysql database credentials to authenticate to a web site (the database was originally only accessed from the command line, but is now accessed from a php frontend). Because of some internal reasons (and to preserve the user's history), I have to leave the old authentication intact. I've been charged with adding openid authentication to this system. Somehow I need to be able to retrieve a users mysql username and password upon logging into the site through openid (using the Zend framework, by the way). I've thought of simply requiring registration at the first login, where the user must provide their mysql credentials, but I'd rather not store the password plain text.
I've also considered blanking everyone's mysql passwords, and just setting the user's mysql username manually (rather than having the user provide this, since they could provide any username).
This is turning into a security nightmare. Does anyone have any suggestions for alternatives?
This is running on a Linux server, by the way. Also, I can't use mysql pluggable authentication because the mysql version is 5.0 (pluggable authentication requires mysql 5.5), and no, I can't update it.
MySQL passwords are hashed, so you will not be able to extract the plaintext password from MySQL. I guess that leaves you with two options, both of which you considered in your question:
The first time the user logs in with OpenID, replace the user's password in MySQL with a new password that is known to your application. Your application uses that password to log into the account of any user who is using OpenID.
Con: A user who uses OpenID cannot go back to using direct MySQL authentication because they don't know their own password anymore. Not even using MySQL command line tools. That implies that users, having once used OpenID, must use OpenID forevermore.
When the user registers to use OpenID, your application momorizes their password.
Con: Your application keeps a list of plaintext passwords
Con: Your application breaks when the user changes their MySQL password by themselves.
Third option:
For each user who uses OpenID, create a second MySQL user for them, which has a generic password. Copy all of the permissions assigned to the normal account to this "shadow" account.
Con: the normal user and shadow user must be kept in sync, so that if some MySQL permissions are added or revoked from one, they should also be added or revoked from the other one at the same time. Forgetting do to this will result in a mess.
Given that you can't sensibly perform openid authentication for the CLI client (even with PAM), I would stringly recommend you do not try to reconcile the openid users with the mysql users - just add a generic user that anyone authenticated via openid can use to connect to the database.
I'm building a website that will require registration and login.
Since I'm new to web developing, i was thinkink if sending unencrypted passwords to the server is an option.
Or, what you would reccomand me, since I don't know nothing about cryptography?
Edit: http://pastebin.com/nYcazcZq
If your website is just for testing or for use within the intranet, it's not that big of a deal.
If not, I highly suggest you use SSL.
If you can't afford the certificate, at least give your users the option to :
login with OpenID (as most OpenID providers offer SSL for authentification) ;
login using Digest Authentication (which doesn't send the passwords in clear over the network).
If you mean sending from browser to your server, then you need to use https/ssl to encrypt the connection, not the password itself. If on the other hand you're talking about storing passwords plaintext, then yes, that's bad as well. You should hash it with a strong salt (per user is best) and a slow algorithm.
This answer goes into more detail about sending passwords over SSL : Sending passwords over the web
You can use PHP's crypt for hashing : http://php.net/manual/en/function.crypt.php
Keep in mind that even when your service doesn't have any kind of valuable payload, it is guaranteed that many of your users will use the same password with it that they use with something more valuable, which means a breach or an easily-intercepted password on your end is capable of causing harm. Even if this is bad practice on the user's part, it's an unavoidable fact of life, so there is really no circumstance under which it is responsible to be blasé about user credentials with a publicly-accessible service. Please use SSL/https or OpenID (or another externally-hosted login management scheme, even Facebook: how to use facebook for user login on my website?) and if you are the password holder, please don't save them in the db as plaintext.
It is never good to send password unencrypted. For a serious web site you should encrypt the traffic between the browser and server using https. You do that by purchasing a certificate that you install on the web server.
never send raw critical data on net,using ssl is best solution i think,also you can use javascript encryptor to encrypt password in client side and decrypt in server,