I'm with some difficulties in make this.
I have a login HTML form, and I want to know if the user and password match with the information in my MySQL server.
What is the best way to do it?
Thank you very much
I know this question is a little old now but I thought I'd answer for posterity.
I think you have a few options.
One option is to not use HTML::Mason for the password validation at all. This is what we used to do. Since your HTML::Mason page is likely running inside a web server you can probably use it to do your username and password validation. For example if you're using Apache and mod_perl to serve your site, there are several modules for authentication, including one that can talk to MySQL and validate against a user table with username and password columns. Check the documentation for mod_authn_dbd for Apache 2.2. I recommend this approach.
Another way to do it is to use a framework like Catalyst. Catalyst already has the plugins for doing the kind of authentication you require and it will save you having to think about a most of the issues you'll need to code for yourself if you try and do it 100% in Mason. You can still use HTML::Mason for your page templates.
If you've got your heart set on using HTML::Mason to do the authentication then I would do it this way:
Place an autohandler in the folder you wish to protect -- note that all sub-folders will receive the same authentication protection
In an <%init> block in the autohandler, check for a valid session token in the cookie. If none exists, redirect ($m->redirect) to your login form. Otherwise, do nothing -- the autohandler will continue running and the page will be served.
In your login form handler, extract the username and password in an <%args> block. Using the username, retrieve the hashed password from the database. Extract the salt, prepend it to the plaintext password provided by the user and re-hash it. Then compare the hash strings. If they don't match, redirect back to the login page with an error. Otherwise pass through.
If parts of the above don't make sense look around on this site for "salting passwords" etc. As the original replier noted, it's bad karma to store plaintext passwords in the database. :-)
Create a Mason component that validates your username/password combination against MySQL with DBI and returns true or false if it is passed username and password in the %ARGS hash. Then load the component in the top of your login form, using the return value to determine whether to show the login form or redirect to your content.
Always store hashed values of passwords. When you have to validate the user credentials, hash the password input by the user and compare it against the hashed password value corresponding to the particular user.
Related
In my app, the user should be able to login regardless whether they are online or offline, so is it possible to add offline authentication capabilities to my app, because I believe the package google_sign_in only does online authentication.
If all you're doing is asking for an email & password, that's fairly simple to check against and you can do it without having to delve into native code.
However, you'll also want to store the password information securely so that will require a little more work.
During registration:
Ask for username and password, then confirm password
Hash password securely (use an algorithm meant for password hashing like PBKDF2, SCrypt, or Argon2, and use a salt. There'a ton of stuff out there on the internet why this is important). There's a plugin for this: password.
Store this hash & the username as securely as possible - flutter_secure_storage seems a good a bet as any although only supports android 4.3+.
Use the generated encryption key to encrypt any data you need saved securely (maybe the encrypt package could help but I'm not 100% sure how complete or secure it is).
If you instead want your user to log into a server the first time and save the password as well, this should be more or less the same process except that you verify that the server accepts the password before/after hashing it.
During login:
Ask for username and password (or hopefully just password or you'll annoy the crap out of your users =D)
Retrieve previously stored password hash + salt
Verify against previously stored hash + salt
Use generated encryption key to decrypt data etc.
A few other things... make sure that the password entry doesn't support autocomplete or the user's keyboard might save their password. If you have a button to show the password you might want to think about blocking screenshots somehow while it's being shown (that's native though). And never, ever store the password in plain text! Using a hash means that at least if an attacker gets in, they won't be able to see the actual password.
Note that while this should work and should be at least moderately secure, don't treat it as a 100% secure solution. You should always get an expert opinion on how to implement your security as opposed to a stranger on SO =P.
There's also a bug open against the flutter google auth plugin about this so it might get resolved at some point that way.
And there is also the local_auth plugin which supports TouchId/FaceId on iOS and fingerprints on android - however, it will only work on android 6+ and with devices that have a fingerprint reader so you may need to have the username/password fallback anyways.
I'd be happy to answer any questions you have about this.
Is it save to create backend user with an empty password?
For example the _cli_lowlevel backend user or a backend user editor-test, which I only use for testing purposes via the "Switch to user" feature.
usually a cli_* user should have no rights to access anything in the BE (non admin user, with no mount-points). it is used to execute TYPO3 by command line. if anyone can get access to a shell he can execute commands more dangerous than a simple BE-access. e.g. he can open access to the install-tool and create an admin-user. or use mysql-cli to set passwords to any given user.
normally you can not create BE-users without password as the form for BE-users requires a not empty password field. as you probably use salted and hashed passwords even a simple password can not be decrypted (so a brute force attack may find the password quickly). so the best way would be a long random password which you might forget the next moment.
Our application has different roles for each user and only certain users are allowed to query the data. We have to validate user id and password for each request.
I have a simple REST get where the user passes employee id and we return employee data. What is the best way to pass userid and password? Is using userid and password in URL (i.e. #PathParam) bad idea?
Right now I have it as follows, this will return the employee data for emp id 111 by user u1
https:../MyRestWebService/services/getEmp/u1/encpassword/111
Only https port will be open in the firewall i.e. all requests are always over https and password is always encoded string (we publish how to encode)
thanks
Whether or not this is a good idea always depends on exactly how you are using it. Passing the password itself will probably raise eyebrows at least, and it could be a serious problem.
Generally, the two approaches are require a login prior to issuing further calls, which mimics what a human user would use the system but requires logic to handle logging in and out on the client side. The second is to use API tokens, which is potentially less secure, but more convenient for automated clients. Note, there's no fundamental reason you can't do both.
Take a look at how github handles API authentication; they actually do both. You can do an OpenAuth authentication to create an authenticated session, which takes the form of a temporary access token used in subsequent requests. You can also create a permanent access token and associate it to the account.
https://developer.github.com/v3/oauth/
https://developer.github.com/v3/auth/#basic-authentication (see x-oauth-basic variation)
You can also use a framework or built in support for sessions (depending on your server stack) to track authenticated sessions implicitly.
Yes, putting username and password in the URI is a bad idea. For starters, it means you can't share the URI without exposing your username and password. Is there some compelling reason you aren't using HTTP Basic Authentication? This seems like the exact case it's designed for.
GET https://.../employees/111
is a much more correct URI.
I have a simple webpage deployed to tomcat which runs certain shell scripts based on user selection. The pages are written in html and cgi/perl.
We already have a working ldap server and directory. I need to be able to add security to the web page I created so a user is asked to login using their ldap account when trying to access the home page or any off the sub pages.
How do I add ldap authentication to my web page?
Please be very specific as I am new to all of this. Step by step instructions including code would be greatly appreciated. Thank You
I did a lot of research on google, but all of the solutions are generic, and I don't know where to start.
This is a good article, but I'm not sure where do I put my connection to ldap and the binding (which of my pages)? How do I make sure the authentication will apply to the sub pages as well, or any other one created in the future?
http://www.perlmonks.org/?node_id=32196
Cheers
This is a good article, but I'm not sure where do I put my connection
to ldap and the binding (which of my pages)? How do I make sure the
authentication will apply to the sub pages as well, or any other one
created in the future?
You're now adding state to your app. You might initially think about implementing your authentication (authn) and authorization (authz) in tomcat, and not in your app.
If you decide not to implement in tomcat, and choose to implement in perl, then you've just decided to add state to your application, which means you need to add some kind of session handling. Look at CGI::Session, there are many other session handling modules on CPAN. Avoid Apache::Session. Its lock handling can cause lots of pain if transactions run long. Use a session key in a cookie. Send everything over SSL. if you don't use SSL, then crackers can intercept your session keys, and then hijack the sessions.
Once you have your session infrastructure set up, you need to create a login mechanism, usually a form with username and password. when that form is submitted, the CGI behind it does its magic crypto on the password and then does the LDAP dance:
connect to the directory server is no connection already exists.
2a. bind to the server anonymously or as an application user, search for the user by CN, bind as the user using DN and password
OR
2b. compute the DN form the username, bind with the DN and the crypto's password.
Often, step 3 is to check the user's record for some authorization indicator, it could be a yes/no access indicator, or it could be a list of roles or privileges.
If the user is successfully authenticated, and authorized, then write some authorization info into the user's session.
Each subsequent page of your app will then check to see if the user is logged in and/or has the proper authz to use that page. If unauthorized, you can either send them back to the post-login landing page, or to the login page if they aren't logged in.
Basically, you just replacing the usual "query the user table of the database" with a query to an LDAP to a directory server.
I am working on iPhone application which have login form to access application functionality same as website. now i want to add one button in iphone application that redirects user in to website in safari browser with successfully login.
After success login in to iPhone application, user want to check website in browser so i just need to add functionality that user can directly login in his account and redirect on particular page.
i have some basic idea for that we can do with encrypted username and password with url.
like http://xyz.com/login/username=abc&password=abc
but i know that its not secure way to pass username and password with url.
So please suggest me any other way if possible.
Any idea or alternative that how to implement this.
Thanks in advance.
There are a few ways to do it.
Any time you send password information over the Internet you want it to be encrypted over SSL. This will require an SSL Certificate for your web server though and it's not always possible.
You can also encrypt the username and password yourself in a way that only your web server will know how to decrypt. So the username "foo" could be turned into "oof" and the password "bar" could be turned into "rab". That way if someone intercepted your requests, they couldn't know what the username and password were without knowing how you changed them.
Why not pass the session id?
Here's what I mean: When you log in to a web site, typically you're assigned (or already have) a "session cookie" which essentially tells the server "This visitor has session ID 'XYZ'", and allows it to retrieve the server side information stored for that user (like who they are, that they authenticated, or whatever else you store in the session store.
One of the easier ways of moving to/from applications is to make sure that all logins generate a server side session, and provide a script which will overwrite the user's session cookie and redirect them to the proper page.
session_restore.php?sessionId=12345&redirect=HOME
The doubters here will argue that providing such a script is tenement to a security breach, but I would argue that all of this information is stored client side already, and can be accomplished without the server's intervention anyway. (session hijacking plugins for popular web sites exist for firefox that will grab session IDs from wireless networks - no technical skill needed)
Doing it this way just makes the process friendlier to the user, and if your site provides SSH access (which you really should be doing anyway) then the risk is very minimal.