I am developing client-server application in Java which need user login. For that I need to show login screen to enter user name & password if username is not there in configuration file (initially it should should be "blank").
After filling the form and checking the Remember Password, I am going to send user name and digested password to server to check. If user is there at server I will get success message then I need to save the username and digested password in a secure file if he check the Remember password checkbox at userlogin screen. For that I need a secure place to store username and password in Windows environment. If I store it in a file, how to secure that file from other users who logged into Windows with other username.
For every Windows user I need a separate login and I am using SHA-256 digesting algorithm to digest password.
How can I do it using Java Swing.
Instead of a file, you should use the Preferences API. On Windows, it will store the data in the registry, in a branch not accessible to other (non-admin) users.
Related
i've connected successfull to Azure Active Directory trough LDAP protocol with JAVA, i'm able to get users and their attributes.
I'm trying to change users's password but everytime i try to do it i receive this error from LDAP: "error code 50 - 00000005: SecErr: DSID-031A1256, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0"
I've checked that the user and credential used for password reset have Administrative right (Global Administrator on Azure).
I've noticed that same problems appears when using LDAP GUI client: it's not possible to change user password because of insufficient right.
I'm struggling on how to do it but i've tried quite all things...
Have you got any suggestions?
Thank You
I'm trying to upload Vosao CMS to Google App Engine. After entering ...appcfg.cmd update ... in Windows command prompt it requested email, then password but I can't enter a single symbol after password request! What am I doing wrong?
As a security measure, the uploader does not echo your password as you type it. Carefully type your password anyway, then press Enter.
I have made a log in and register system in java using MySql database (Connectpr/J driver). The username and the password are stored on localhost in a database. When I log the user in I check if the username matches the password in the database. The question is how can I keep the user logged in if he closes and reopen the program. Should I save in the database the currently logged in user? Is it the right way to do it?
You will need to store the username and password if you do not want the user to type it in again. if this is a web application then you can use this w3c cookies
if it's not then you can save it locally on the users machine but use some encryption logic for this have a look at the following thread
MD5 encryption
No, you need to save the user info (user name or user id but NOT the password since its a security risk) in a cookie (docs) which is stored on user side so when he opens a new session you have to check the cookie and log in automatically.
Steps :
user logs in for the first time
save user info in cookie
user closes current session
user opens new session
read user info from cookie and log in automatically
If its not a web application you can simulate the cookie behavior
I have a (java) web-application, and i have enabled NTLM Authentication.
When the logon prompt is presented by the browser in our (windows) intranet environment.
The behavior i see is:
NTLM prompt does not seem to be doing any authentication at all, i am able to type any random string in userid prompt and it allows the user to proceed into the application. The prompt never fails the user.
So, what do i need to check at the server end to find if authentication succeeded or not?
The idea behind NTLM auth is that the logged on user can proceed with connection without explicitly entering his username and password again. So whatever your application asks you is irrelevant (as you can see it yourself) and instead your system credentials are used.
NTLM authentication has been broken for a number of years -- NTLM 2 shipped with NT 4, so hopefully people have moved on by now. If you want to use Active Directory login information, you should use Kerberos instead.
I started a project setting up basic authentication. I now want to switch to Digest Authentication. The problem is that the authentication is validated only if I provide the hash of the actual password, and not the actual password.
I did the following to switch from BASIC to DIGEST:
changed in my web.xml the auth-method to DIGEST
changed the JAAS context of my JDBC Realm to "jdbcDigestRealm"
in my db, I used to have "password" as a password, I changed in to the result of MD5(webuser:postgres:webuser) (where webuser is the login, webuser is the password, and postgres is the realm), in other words I set the password in my table to c3c2681ed07a5a2a5cb772061a8385e8.
The problem I have is that the login popup is displayed by the browser when I try to access the resource, but using "webuser" as the password doesn't work. However, using "c3c2681ed07a5a2a5cb772061a8385e8" as the password works. It looks like I'm still in BASIC authentication mode.
Any clue ?
Thank you !
The DIGEST auth-method is same as HTTP Digest Authentication. It just encrypts the communication between the browser and the server. The server still has the password in plain text.
From http://java.boot.by/wcd-guide/ch05s03.html:
The difference between basic and digest authentication is that on the
network connection between the browser and the server, the password is
encrypted, even on a non-SSL connection. In the server, the password
can be stored in clear text or encrypted text, which is true for all
login methods and is independent of the choice that the application
deployer makes.
You should set the digest-algorithm property of your JDBC Realm to MD5. After that the JDBC Realm will hash the password.
Perhaps you may need to change the digest algorithm in the realm view from glassfish console to MD5. Default value from GlassFish 3.0.* is still MD5, but from GlassFish 3.1.* has changed to SHA-256. This could be solution.
Adem