20

I am trying to see if a webapp transmit password in some form of cleartext. The problem is that the web app is NOT using https! This is why I wondering is my passwords is sent in clear text.

I've found a cookie in my browser containing the following :

usr=waytodoor&mdp=3C5115ECB18725EBFFF4BB11F9D17798358477D6E11E0188D54BAB80C86D38D41A16F76D8D0B253445774484FB1AE22E9FC13E257CFB9E7B7466F1BA5417EA004FCBB4E7965CA571819146A148EED15A2AEA6E47D9DF338B534264FBC99A57952212629BA79BB34BE9C8C60B73F1F681EE872C64

From what I can tell, usr is my user name, and mdp ("mot de passe" in french means password).

So, is the mdp field of the cookie my password (and, if it's the case, how could I "decrypt" it ?), or just some kind of token? The password is 7 chars long.

I tried to convert it from hex or from base 64, but no luck.

EDIT: Included statement that HTTPS is not being used.

EDIT2 : The website is a webstite for students. Passwords are given by the school at the beginning of the year. We can't change them.

I suspect that some students are ARP'ing the school network. I try to disconnect as fast as possible from the website to invalidate the cookies, but I wanted to know if they can find the password from the cookie.

|improve this question
  • 6
    You could create two accounts, using the same password for both. Then switch the cookies, using one user's usr cookie together with the other user's mdp cookie. If that works, they're doing something weird. – CodesInChaos May 12 '16 at 14:03
  • 1
    You haven't mentioned which webapp this is. Not using SSL - especially since certificates are free - is pretty much heresy these days, so I'm curious who this is. – adelphus May 12 '16 at 17:21
  • 1
    If its not using HTTPS you're vulnerable to MITM regardless of whether the app is sending your password in plaintext or not. An attacker could inject JavaScript into the page you're receiving to log your keystrokes, or do any number of other things to steal your password or access your account, regardless of what the web app normally does with your password. – Ajedi32 May 12 '16 at 20:52
  • 1
    As a writer of web applications I can tell you that passwords are not encrypted on the the front-end (in the browser) they are sent in plain-text over https which provides the encryption for all of the communication. They are then hashed & salted on the server where the programmer knows the user hasn't been able to do anything fishy to the code. From that point on the company should never ever be able to tell you what your password is, because hashing+salting correctly should be irreversible in normal time. Also that hash should never leave their server. The proper identifier is a session id. – Ryan May 13 '16 at 0:22
  • 2
    @adelphus If an attacker is able to read the data on your server, you've got bigger problems than just possible password harvesting. Not to mention that validation should be server-side, not client side, so the server would effectively be using the hash it received from the client as the password anyway. (Could be effective if your only worry is about users' accounts on other services with the assumption they reuse passwords, though.) – JAB May 13 '16 at 15:41
35

There are two reasons to ask if your password is being encrypted:

  1. You are worried about the security of the site.
  2. You are worried about the security of your password.

Regarding site security, with no HTTPS, there is effectively none. You should consider every communication with the site as public and assume that an attacker can pretend to be you. Just use the site with care.

Regarding the security of your password, without SSL, it doesn't really matter. Someone can steal your session cookie and pretend to be you without knowing your password. So be sure not to reuse the password on other sites (or reuse any password ever) to prevent a password exposure on this site from compromising your accounts on other sites.

Edit In response to your concern about ARP spoofing, without SSL, it may be possible that they establish a MiTM. Once they do that, they can see the cookie. Without deeper inspection of the web site, I cannot tell you if the cookie leaks your password. Perhaps it is securely encrypted, perhaps not. That said, once they have an MiTM, they can alter the JavaScript that is sent to your browser. This would allow them to alter what is sent on the wire, thereby getting your password. And, while I can't be certain without further examination, that cookie is looking to me like a pass the hash vulnerability. If that is the case, then there is no need for them to steal your password as the cookie's value is as good as a password. All of this boils down to, without SSL,there is no security.

|improve this answer
  • 8
    Very important! No auth scheme can protect you if HTTPS isn't present. – BonsaiOak May 12 '16 at 17:50
  • 10
    Blunt and to the point: "Regarding the security of your password, without SSL, it doesn't really matter." This should be marked as the correct answer. – TTT May 12 '16 at 19:31
  • I'm accepting this answer because it has the most upvotes. However, every other answer had been helpful, so check it out and upvote them. Thanks for help everybody – WayToDoor May 22 '16 at 21:54
20

What you got there is 232 hexadecimal digits, or 116 bytes of data. It is not a plain text string in any normal encoding. It could be a hash of your password, it could be your password encrypted, it could just be some kind of easily reversible obfuscation. Or it could be something completely different from your password, like a session identifier. It could be anything. Without knowing your password or the code the webapp uses it is hard to tell.

But if you are worried about the safety of your password when it is on the wire, it really doesn't matter. What matters is that you use HTTPS.* If you use HTTPS, everything sent between you and the server will be encrypted anyway. If you don't, there is no way to guarantee that a man in the middle can't steal your password, no matter what kind of encryption you try to do on the client.

Usually the only encryption used when sending a password to the server is the one that HTTPS provides.

That said, keeping the password in a cookie (wheater or not it is in plaintext, encrypted, hashed or just obfuscated) is a bad idea. Anyone with access to your computer could steal the cookie, and if the cookie is not HTTP-only an XSS vulnerability could be used to steal it as well.

* Given that it is good HTTPS - that the certificate is valid, you use a modern version of TLS, etc, etc. The same caveats that always apply.

|improve this answer
  • The problem is that the web app is NOT using https! This is why I wondering is my passwords is sent in clear text – WayToDoor May 12 '16 at 13:16
  • 7
    @WayToDoor If it is not using HTTPS there is no way to make sure your password is safe. Even if there were some kind of encryption happening on the client, a MitM could simply fiddle with the script doing the encryption or steal your password before it is encrypted. The only way to be sure would be to carefully inspect the source code on every login, an near impossible task. – Anders May 12 '16 at 15:00
7

When you want to eavesdrop on the communication between your web browser and a server, you can often do that with the developer tools of your web browser (usual hotkey: F12). Most browsers will have some kind of Network tab where all network communication between the current website and the internet is logged in cleartext.

When you find your cleartext password anywhere in there and it's not a https connection, that's a bad sign (when it is https, the browser will show you the data unencrypted, even though it was encrypted when sent on-the-wire).

But even when you find an encrypted/hashed password in there you won't know if it is good cryptography. You generally can only tell by using cryptoanalytic techniques until you figured out how the encryption works or if you reverse-engineer the javascript code on the website to find out how it works.

|improve this answer
  • 1
    An external tool like Fiddler will help see that it is encrypted over the wire. It also keeps history better than the F12 in most browsers I find. Still F12 will probably get the job done. Your comment about "encrypted vs encrypted well" is also particularly relevant. – corsiKa May 12 '16 at 17:09
  • A note about using the developer console in Chrome: if the webpage refreshes when you log in, enable "Preserve Log" to see network transactions between different pages. It can be annoying trying to read the data being set to the serve when the page refreshes, blowing away all of your network history. – d0nut May 12 '16 at 18:12
1

This is how normally you investigate this. If it is a hash of your password, then you could test your password with the hash function and compare the output. This particular (assumed) hash string has 232 hex-digits, which equals to 928 bits. This is the exact size of RSA-280 number, which is used in SHA-1 encryption (along with many other RSA numbers, so you cannot be sure without trying the function).

https://en.wikipedia.org/wiki/RSA_numbers#RSA-280

RSA-280 has 280 decimal digits (928 bits), and has not been factored so far.

You could open the web page source code, try to find the module that has something to do with SHA-1 (in this case), then find the hashing function inside of it and then execute it using browser dev tools or node.js like this:

console.log(hashingFunction('yourpass'))

Then just see if the output is the same 232 characters. Please notice, that finding the hash function could be tricky, it could be obfuscated, downloaded long after the page loads etc, and you will need some JavaScript knowledge obviously.

|improve this answer
0

There're two possibilities, your password is either encoded or encrypted into that string. If it was encrypted, then it can only be decrypted using the key defined in the webapp, which is quite secure and need a long time to try breaking it.

|improve this answer
  • 5
    There's a lot of assumptions here. If the key is present on the client side of the webapp, it's only secure if it's using a asymmetric cipher and the other half of the key is held somewhere else. Even if the password is encrypted, there's no security in the connection itself (SSL), so anyone can intercept and change the data without you or the server knowing. – adelphus May 12 '16 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.