One of my colleague in QA team reported a bug to me, the bug said that can't change password to lowercase, otherwise login was rejected,using number or uppercase was all fine. The login system was implemented using acegi 1.0 (now called Spring Security).
This was a very strange bug,changing password is done by encrypting the user input string into MD5 string, I implemented this without using anything related acegi, I don't if the is the origin cause of the problem.
When the login is rejected, through debugging, I find that, the user input is converted into uppercase by acegi when passing to the acegi comparing logic. At first, I didn't believe this, when I checkout the acegi source and debugging with it, I find it does convert both username and password to uppercase (source code line 121), Can you tell me why it does this? This can cause password encoding mismatch!
Thanks matt, some guy in my team chose the Siteminder implementation of Acegi, which was the cause of this problem.
Related
We are using keycloak standalone server to authenticate our users.
Social IDPs: google and facebook login work perfectly, except the following mistake:
If on your google account first and last names are written with non-ascii
characters, keycloak doesn't read them properly.
For instance: Name on the google account is Собиров Валижон.
What I get on keycloak is Собиров Валижон
Steps to reproduce the issue:
add test realm and client
add google identity provider settings
login with google user who has non-ascii chars in first or lastname (in my
case Собиров Валижон)
see keycloak test realms user database
It would be appreciated if someone could solve the issue.
screenshot from keycloak account
screenshot from google account
The only solution I could find was to put default encoding in JVM.
Add default encoding to standalone.conf
JAVA_OPTS="$JAVA_OTPS -Dfile.encoding=UTF8"
Try read this internationalization issues in official documentation. I also had troubles with non-ascii chars and it helped ;)
https://www.keycloak.org/docs/latest/server_development/#internationalization
And maybe you should see your keycloack settings in keycloack client like here. I assume that your language need to be allowed here.
I've configured servlet, and other things needed to have role-based access to resources. I'm using JDBCLoginService to access roles data from DB. All works great, my only problem is: how to configure Jetty that in database I'll have passwords encrypted (preferably not MD5).
I found several docs saying you can run some tool given by jetty and it produces you MD5 or OBF, etc. But I wonder how to get list of avail ciphers?
I believe in table with users, column with password should have something like "MD5:897897979".
But I want to add users to this table by functionality like register/signup. So I need to encrypt password sent from browser and put to DB. But I can't control algorithm which is used by JDBCLoginService to check data sent by user from login page.
I believe it's implemented in some smart way that not much extra code is needed, but I can't just find info how to do it :/
I had a similar problem and tried to resort to the facilities provided by the Password class in the Jetty distribution.
However, eventually I couldn't adopt that approach since I was in need of storing the passwords hashed with a specific algorithm (namely sha256 or sha512) and I couldn't find a way to get the JDBCLoginService work with such hash algorithms.
This was kind of a let down, especially because Tomcat comes with the support of those algorithms out of the box when it comes to handle database-backed authentication scenarios.
I found this problem today. And the solution I ended doing is to have the sha256 calculated for the password input field in the browser side. You can do it on form submit or any other event if you are careful not to re-hash. Simple check or password length less that 64 would be sufficient to avoid rehash. I used the below to do the hash
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest
Paradoxically this solution makes it stronger as the password is hashed from the browser itself. Of course it could be exploited from this same web app but not in others that do not use hashing from browser if the is is used for other authentications.
I have been trying to use the java jdk to Couchbase. sdk v 3.2.3
However I find it strange that the examples provided never supply any password while connecting. Also I created a read-only user, and I see that the there is nowhere to provide the user-name while opening a bucket from a cluster, you only provide the password. I tried using the password for the admin and for the read-only user that I created. But it would fail with couchbase.client.java.error.InvalidPasswordException: Passwords for bucket "myBucket" do not match. It is the same password that I use when I login to the admin console, yet this password doesnot work. Only the empty password works.
I am confused and don't get the hang of it?
Anybody knows about this?
My aim was to create a read-only user and use this user credentials to only read data from couchbase for a specific module which is only supposed to read data.
At this moment, there is no read only data access to a bucket in Couchbase. Stay tuned as there will be lots of security changes in the coming versions of Couchbase.
I deployed an existing Maven project in my Tomcat Server on Windows7 environment. I'm using tomcat7 , spring-security-core 3.1.0 .
However, everytime I'm logging in my webapp, I received an error
java.lang.IllegalArgumentException: Non-hex character in input
The code is working perfectly fine in Linux environment. So I was thinking it's because I'm using windows7 in my local environment. When I look into the internet I saw that's it's a encoding issue between linux and windows.
I tried setting up
JAVA_TOOL_OPTIONS -Dfile.encoding=UTF8
but haven't succeeded. Please help me out. Thanks in advance!
Most likely, when you login, events happen is such order:
Spring selects an entity from DB by username.
Spring must check inputted password for match with stored encoded password.
To check for a match, Spring uses PasswordEncoder, which you have most likely configured.
Your password encoder expects that stored encoded password is a hexidecimal char sequence (previously encoded by this PasswordEncoder). Thus, it tries to decode CharSequence into byte[], but fails (source).
The solution is to persist users with previously encoded password, e.g. by BCryptPasswordEncoder.
Answer Alex Derkach is right for me!
In my case i have DB with straight store password(develop) looks like User=roor, psw=root.
So when i comment(delete) .passwordEncoder(new StandardPasswordEncoder("53c433t")); ! its work
!!But is wrong, password must be stored in encrypted form!!!
A possible reason for this is mixing password encoders. There're different implementations of PasswordEncoder. And, for example, if you use SymmetricPasswordEncoder for encoding and StandardPasswordEncoder for decoding you may get this exception.
I just upgraded to the latest axis2/rampart version and encounter a strange behavior when providing a webservice which requires username-passwort authentification.
up to now, I implemented my own passwordcallback-handler which handled WSPasswordCallbacks of type WSPasswordCallback.USERNAME_TOKEN_UNKNOWN. I looked up the provided user in the DB and checked the given password.
in the latest version, the passwordcallback-usage always seems to be WSPasswordCallback.USERNAME_TOKEN where I have to provide the password for the given user - but I'm not able to provide the password, because I don't store the passwords plaintext.
do I have to write my own org.apache.ws.security.validate.UsernameTokenValidator? where do I have to register it?
I wrote a summary here on Stackoverflow of my encounter with this problem, and the workarounds I've found to this, read it here.