I have a wildfly 21 installation with a management user (added using the add-user.sh). I forgot the password and I was wondering if it's possible to decrypt the value stored in the application-users.properties instead of generating a new one.
The password is only stored as a hash, so you will not be able to decrypt it.
And trying to break it might not be worth the effort.
I would just use the add-user.sh script and add a new user with the same name again.
It will then ask you if you want to overwrite/update the user and you are able to supply a new password.
Related
I'm moving out of Liferray 6.1, to a custom application. I want existing users to be able to login in the new application with existing Liferay credentials. When user logs in for the first time (not yet having an account on the new system), I want to be able to check his passwords against the Liferay's user_ table and on success create an account in the new system. There will be no Liferay running nowhere so I cannot use Liferay's services for that purpose.
The question is how can I compare the user provided password to the encrypted password stored in user_ table?
I have tried to add the portal-service.jar in my new application but some errors happens like :
com.liferay.portal.kernel.log.Jdk14LogImpl error
SEVERE: BeanLocator is null
First you need to check how is(was) your Liferay 6.1 configured. In the portal.properties there are few setting related to passwords. Check the value of passwords.encryption.algorithm. It is by default SHA (SHA-1) in Liferay Portal 6.1
When your users log in, you will have to encrypt the password they provide using the same algorithm that your Liferay Portal instance was using and then compare the encrypted strings.
Depending on the algorithm you may or may not need Liferay Portal's API/utils for that. Have a look at PwdEncryptor class to see what was used to encrypt the password and follow the same approach.
Keep in mind you will not be able to decrypt the password. But you will have it unencrypted from your user's input. So once you confirm the user's credentials you can store the password in your new system using any encryption algorithm you wish.
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.
I am making some scripts for personal use. I need to store user and passwords for various stuff. Is it safe to store password text on webserver outside the webroot, eg
/var/www/includes/? Should it be encrypted as well? Or should I encrypt the password and store it in a database?
I'd suggest tu use the file .htpasswd to manage passwords:
http://www.htaccesstools.com/articles/htpasswd/
The file contains unencrypted usernames and hashed passwords.
It's one way to protect web ressources from unauthorized access.
The attached screenshot shows how the login will look like!
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.