I am currently attempting to develop a quick tool that would allow me to check my cellular plan balance (carrier being MetroPCS). To do this, I need to be able to login to the metro website with a library (like python requests) that does not render javascript. While checking the post request for the login form on metro's website, I noticed that the password field (labeled "verificationValue") seems to be encrypted. This obviously means I cannot login with a plain text password. Encrypted pin number
I have attempted to look up ways to somehow trace back the javascript that may handle encrypting the password field before it is sent as a post request but was unable to find anything that I could understand.
you should try to find a way to interact with the service directly, bypassing the login form. For example, you might be able to use an API provided by the service to check your balance, rather than logging in to the website
Related
Story
I'm using SQL Server database, and there is a table called aspnet_Membership that it seems like it's generated by ASP.NET. The system's frontend no longer uses ASP.NET but still would like to authenticate users from the old database.
What I know
The Password and PasswordSalt columns in the table I think are essential to authenticate a user, however, I don't know what encryption method was used in the system.
An example of a password looks like this: K9YjVGWxF4bPQCvQ8VYA1vbQyCE= and password salt looks like this: CM9k+UbZuKTuFxI46vIVIA==.
There is also a PasswordAnswer field that it seems like it uses the same encryption method, but I don't think it would matter in terms of authenticating a user.
Question
How can I authenticate a user by the given password and salt (ExpressJS preferably)?
Thanks
You will need to find the method which is being used for logging in. In order to do that, open your web-browser, go to the main page of your application, open dev console and view the Network tab. Then log in, see where the request is going, analyse the code and find the method which authenticates your login.
Another way to find that method is to search for the usages of the Password field of the ORM used (if an ORM is being used) and finding where it is being stored at registration or settings edit, or when it is being authenticated at login.
If this fails as well, then search for the word of password in the entire source-code and see whether you find the authentication of password or the way the password is stored.
If this fails as well, search for the word of salt in the source-code and see if you find any useful results.
If this fails, then search for words like login or authenticate in your source-code.
And if all these fail, you will need to either get creative in your search or ask someone in the team who knows the answer.
When you find a method which takes a String as input for password and generates another String as output and checks it against your password and salt, then you found your method. Once you find your method, you will just need to ensure that you use it in your project or implement a similar way to authenticate users.
Indeed it is an awesome day to everyone but not for me because I've been handling this battle cry for more than 13 days now and cant get it done. I have searched across the web but cant find the solution that can get my butt out of this mess. And yes stackoverflow is always my last resort when things get worse.
Can anyone suggest what is the best way(or even alternative) in sending email using js or jquery ?. Perhaps a simple snippet would do. Thanks!
You cannot send an email within the client browser. If your website is running on your own webserver, you can send a request from within the browser to your server that sends an email. If you're running a node.js server, there are many email apis.
For example, my business is a Mailjet customer, and so I can use the node-mailjet api on my server-side. Also there's https://nodemailer.com/ and similar npm packages.
Sending email only using javascript on client-side is not possible. By that you would give full control to user what and where he sends email - cool spam solution..
I wouldn't recommend to expose service from server that send email to client-side from server-side with full settings of message that will be sent. You don't want to allow spamming.
Only good approach is to predefine email on server and then when triggering action occurs resolve dynamic values in email on server and send email from server. Still you have to ensure user cant spam with some security policy.
So how to get out of this ? Implement service on server that will send emails for you (called with AJAX), lets say by code name and parameters. On server-side, choose template by code-name and resolve it by parameters passed with server request. Implement you security policy so you can be sure user cant spam (for example when user can choose to which email address will be message sent). Then pass it all to SMTP.
I have a WebAPI application which is working fine. There are no problems loging, registering etc. However, I come across something which requires some attention. When somebody is registering or logging then their passwords are sent in plain text. I know we can apply HTTPS certificate and this will be solved. However, I am more looking for a solution where I can hash password and WebAPI can automatically pick it up. I am not looking to make changes to built in WebAPI functionality to hash and store PW. This is to also make sure that when I am using FF or Chrome developer tools then nobody can read the PW from data being sent.
I am using Angular or JQuery AJAX to make calls to my WebAPI.
It is possible to encrypt the password in the frontend and send the hashed password and salt + rounds (when used) to the server.
Problem arises when the user tries to log in, you need to get the salt and roundings to the frontend, hash their password (which the typed in) send it to the server, there you do a compare like hashedPassword == hashedPassword and return true/false.
So in my opinion this is less secure than just doing all on the server side. Only benefit is, that no one can see your password in your dev-tools or in the payload.
I’m trying some little ideas, and I’ve hit a snag.
At the moment, when a user logs in, their password is stored in a variable which is handled later. Obviously all one has to do to get hold of the password is to go into the developer tools or console or whatever and add a statement like alert(pass.value);.
I know this is unrealistic but its been bugging me. Is there any way of detecting an alert statement and scrambling the password somehow? A regex or string replace?
Thanks!
If you want to have a secure system, don't store the password on the client side. There is absolutely nothing you can do in JavaScript that will prevent somebody from accessing the password if it is stored in a JavaScript variable.
All of your authentication should be handled on the server side. If you are storing passwords somewhere, do not store them in plain text, and do not use a home-brew encryption method. Cryptology is full of minefields and it's very easy to get something wrong, and I would recommend using a well thought-out system like bcrypt.
I would advise against keeping any kind of credential information client-side. One viable solution that's easy to implement is is a security token password. A simple process would look like this:
User access website. Informs credentials.
Website validates credentials. Creates temporary token associated with user ID, stores it client-side.
User access website. Informs token.
Token is validated against storage, user identified.
given the following scenario: We have a html form for changing an account's password. It looks like this:
CurrentPassword: __________________
NewPassword: __________________
NewPasswordAgain: __________________
We want to send this request via an ajax call. If we send it and we leave our computer (without logging out and staying on the exact same page) someone could open the webkit inspector (or firebug) and see something like this:
http://cl.ly/3y213W1q0U2y2e251k0O
What would be your solution for making this more secure? Is it even possible using an ajax call here or would it be better to use a "normal" html form which reloads the whole page after sending?
Using a "normal" html form has the same problem, as packet sniffing could reveal the same data in a POST or GET header just as easily.
The best solution I can think of is to encrypt the password user-side via javascript. You don't really have to worry about the "what if the user has javascript disabled?" case since, in that case, the AJAX request won't go through either. Obviously this may have ramifications regarding how you store the password, but it will allow you to continue to use AJAX requests for the password update.
The author is not interested in encrypted connections here. He may as well be doing that already. What he wants is to be able to hide the password (and username) from any one who has an access to the computer, and can open the inspector tools to view the networking that occurred on the page.
One of the simplest things you could do is to refresh the page in case the authentication succeeded.
Something that you should do is to refresh the page whenever the user pressed "log out". This should clear all previous network data.
The less good options are about encrypting, obfuscating and hashing the password prior to sending it.
Hashing the password on client-side is not ideal because this prevents the use of hashed passwords with keys on the server-side (think HMAC). HMAC'd passwords are the best, because the key is kept on the filesystem whereas the salt is kept on the database. Cracking the password hash requires a rather solid access to the system.
Obfuscating and encrypting the password can be reversed. If someone sees a login request on the Webkit Inspector, he might be very interested in spending the time to undress your defenses.
I highly recommend refreshing the page at some point to avoid the problem entirely. Other options do not seem as good.
Encrypt the password on transport and make sure the calls you are making are being done over SSL!
To make this secure without using SSL, hash the passwords on the client using SHA-2. While that will protect the password itself, it won't protect someone from sniffing the hashed password. So you can't simply authenticate with the hashed password, either.
One way to do this is to use a server-generated random salt when authenticating. To authenticate, the client requests salt from the server, then hashes the password once (in order to match the hashed version stored on the server), then hashes again using that salt that it received from the server, then finally authenticates using a second ajax query with the salted-hashed password.
The server will authenticate only if this matches its own stored hashed password, hashed with the same salt it previously provided the client.
This way, it is impossible for someone to authenticate using the simple hashed version of the password. Since each salt provided by the server is valid only once, it would be essentially impossible for someone to intercept it and authenticate. (They would have to intercept the salt request, and then try to authenticate before the legitimate client could, all the while spoofing their session).
This protects users' passwords without using SSL, prevents logging in using data intercepted while the legitimate user is authenticating, and is fairly easy to implement. Of course there is no substitute for SSL as far as protecting the actual data on your site, but for a lot of typical web sites where there's not really any sensitive information, you should be more concerned about preventing theft of your users' passwords since people use the same password so often. This addresses that problem.
Note that this also does nothing to prevent session hijacking, but you can minimize the risk and damage of this by doing things like including browsers-specific information with the users's session, and allowing only a single active session at once, and requiring re-authentication to change email address or password.
Depending on the level of security you need, you could use RSA and public-key cryptography to encrypt the password within the browser prior to sending the ajax request. On the server-side, you would decrypt the passwords and process them as normal.
Of course, you would also need to be careful to delete any variables used to hold the entered passwords, and I am sure there are other security holes in this, but encryption will at least offer you some large degree of protection against that sort of attack.
Here's one library I found with a quick search. (disclaimer: I have not tested this, but it looks pretty good)
Lastly, I would strongly recommend that you transmit all login information via SSL. This adds an extra layer of security on top of the whole browser session between the browser and your server.