Click here to Skip to main content
15,662,507 members
Please Sign up or sign in to vote.
1.00/5 (2 votes)
Hello everyone!
I dont know if this is the right community because i dont have any code for you, and just a few informations i can deliver.

I work for an IT company, installing standard software etc.. now we have some customers crying because they have good IT persons and they can login with any account just with html POST, without knowing the password.

What i know is: the software i am talking about is a webservice with webinterface for login. A oauth request is send by the login form. In this oauth request we have the client credentials, username and password (hashed or enrypted idk).

This is ok, we dont want our passwords in clear text. But if we copy this request and send the same request some days or weeks later we still can login with the same password data.
So users in the same network can capture the request and just store them for later or somewhat.

How can this be? I thought the key will expire?
We need to confront the product owner with detailed information before they do anything..

Thanks for help and sorry for not the best english

What I have tried:

I tryed google "javascript password encoding" to understand basic things...
Posted
Updated 19-Jul-19 4:34am

If you're encrypting the user's password, then you're doing it wrong. You should only ever store a salted hash of the password, using multiple rounds of a cryptographically secure one-way hashing algorithm.

Secure Password Authentication Explained Simply[^]
Salted Password Hashing - Doing it Right[^]


If you're hashing the password on the client before sending it to the server, then you're still doing it wrong. The server receives a value from the client and compares it directly to a value in the database. The password hash is essentially the password now, and you're storing them in the database in plain-text. An attacker doesn't need to prove that they know the password; they just need to prove that they know the password hash.

You also won't be able to salt the password properly on the client, since you need a unique salt value per record.


You mention copying and re-sending the request, which suggests you're worried about attackers intercepting traffic to your service. There's a simple solution to this: HTTPS / TLS. All requests to your service will automatically be encrypted in such a way that only your server can read them. All responses from your service will automatically be encrypted so that only the user who made the request can read them.

HTTPS - Wikipedia[^]
 
Share this answer
 
If you are sending the encrypted credentials then that will never expire as long as the account is valid. If you want the logins to expire you'll need to generate a token that the client can use and that token will have an expiry date.
 
Share this answer
 
Comments
SubbZer 19-Jul-19 5:07am    
ok thanks, i understand. But if we ask the user to login 10 times, we have 10 different types of password data and all of them are usable anytime.
Maybe i am wrong but if i use the same enrypting everytime i must always have the same result?
I dont understand how the server can know about all of these datastrings without any token or constant enrypting method.

My problem is that i have to help our customers, if there would be the same datastring anytime i could filter the requests from other pc then the owner ones. But if the owner always generates a new one and none of these will expire it gets hard for me to help..
Software owner is contacted but will need for sure few weeks..
F-ES Sitecore 19-Jul-19 5:12am    
Without knowing exactly how the system works it's hard to say why anything is happening, or how things can be changed.
SubbZer 19-Jul-19 5:26am    
Yes it is. But we dont want to change anything. We want to tell our customers how they can protect there users. And if the bad guy logs in and do some critical stuff its ok, as long as we can secure that not the correct user form this company did this..

We currently try do develop an custom login form, copying the very first login request for a new user and always send this request to the server.. so from now on the users have to login 1 time with the real login form to get the encrypted password and from this point on they have to login with our form and with the enrypted password in the password field.
I think with this way we can ensure always the same userid in the html request and we can deny any from other pcs.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900