I recently logged into a website (student run club website which stores event and participant information).
After successfully logging in the following message appears and follows me around for the rest of my time on the site:
You are using an insecure password. The password that you entered has
been exposed in at least one data breach.
How do you know my password is insecure? This password appears in a
database of known passwords. Hackers may use this password to try to
break into your accounts.
While I appreciate the notification that my password was compromised (and should know better and will change and stop reusing passwords etc etc) I now worry about the overall security of this site.
I don't know a terrible lot about web dev but my naive assumption, given this message and the fact that it appears after log in, is that my password must have been stored in plain text for them to be able to check it against a database. Is this correct? Or is there some clever secure way this could be done?
Just because you are receiving a notification from the site doesn't mean that your passwords are being stored in plaintext. Whatever website you are using can use your password in the "Have I Been Pwned" API before encrypting them. This of course doesn't necessarily mean that they are encrypting them as there isn't really a surefire way to know how they are storing your passwords without possibly contacting the owner or if you were to receive an email at a later date with your password in it.
You can read up on the API for password checking here haveibeenpwned.com/API or you can check for the website you are using in this list here haveibeenpwned.com/API/Consumers.
Related
I am trying to solve the classical approach to how user login pass token is stored in web browsers. By default, anyone who can access the developer's consoles of the browser can obtain the content in password fields by looking at the HTML content of the input element or using javascript.
Because of this, if by mistake someone comes across your login password, he/she can use it on any browser to access your data from the server.
To solve this problem, I am researching a way which on an attempt to login the server will generate a unique pair ID from the client's Unique ID and let the client store this server generated ID as the user's login pass for this client only, such that if the server generated ID is used in attempt to log in from another browser, the server will compare the associated browser ID to the accessing unique ID before permitting access.
Consequently, A server generated login can only be valid on the client who generated the ID, the real password is never stored on the client, but only used on the first attempt to login on a client who does not have valid server ID. The user will have the opportunity to invalidate all the server-generated pass.
For this to work, I need a unique token from the browser such that if 10 instances of the same browser are installed on the computer within a time-space less than 1 second, the ID of this browsers will never be the same.
My question is, can such Unique ID be obtained from the browser? any suggestion on how to go about this is also appreciated.
In general, you can't uniquely identify a browser installation in the way you describe. This is, in part, to protect users' privacy from tracking across the web.
Your ultimate goal (preventing an attacker from authenticating if they discover the user's password), however, can be satisfied with a one-time-password system, like TOTP.
In a system like this, when an account is set up for one-time passwords, the user and service share a secret. Later, when the user logs in, they are prompted for a one-time password, which they generate using special software, which is isolated from the client, and ideally on another device. For example, the user might use the Google Authenticator app on a smartphone to generate a code that they enter on their desktop browser.
Even if the attacker captures the user's conventional password with a key logger, they can't authenticate themselves because they don't have access to the shared secret necessary to compute the one-time-password.
Universal 2nd Factor authentication is another approach to thwart key loggers based on some parallel concepts. (That is, it also uses a one-time code, generated with a secret that is securely stored rather than being exposed on the client.)
I am very sorry if this has been answered before, but I have searched for 2 days and cannot find the answer. I have 2 databases and I need to import users from the current database to a new one. The new database is for a chat system that has recently bee installed and I would like all users to be added to it.
So I thought I would simply manually add the users in the new database using information from phpmyadmin. But the encryption for the password is a different format and will not work.
For example in the first database the encryption is:
z70I9QINffX2Hh7FxQ==
In the second database the format is:
3eb5c61f784aa3c2e11d879382387d420f7c4ebf
Neither seem to be MD5 and I can't find out which type it is.
I know this is a stretch but does anyone know of a way to detect the type of encryption and how I can take a password, such as 'password' and encrypt it using the correct encryption type?
Thank you
You could try using a generic password for the root user, or logging into mysql as the root user & creating another user manually. Not sure what kind of access you have, but that's been the best bet in my experience.
Hope it helps.
The password encryption mechanism would be stored in the application's code. The 1st example looks like Base64 but can't be sure without comparing others. The 2nd example appears to be SHA1/MySQL5 Sha1(Sha1(pass)).
You're going to have to research the apps that are using these databases and to determine how it's creating and storing these account passwords in the database. Either way, you are trying to link 2-dbs that have different password mechanisms, that might require standardization of the passwords which might mean a password resets.
There is a harder way, you have a database of one-way hashed passwords. It will require a bit of focus in scripting... You would have to generate hashes for the cryptographic hashes used and compare to your users passwords to get the plaintext password. Then you recreate their accounts in the new DB using their passwords to create the new user with same credentials.
I'm working with an app that provides basic username and password authentication to access their API. Specific access to this api would be on an user-by-user basis and their rights in the external application. What is the best way to store these external credentials, and what is the best say to pass them back to the app?
I'm currently working with Node.js using Express, and MySQL.
I'm looking for specific technologies to possibly use? I'm a bit new, and was trying to hash them and save them to the database, but then I don't know how to send it back to the application...
Definitely don't try to roll your own security, invest in an a proper, industry tried & tested, user authentication service like:
Okta
AWS Cognito
Azure AD B2C
Auth0
And the likes, you won't regret it.
Hashing the password to store it in the database is usually the least you should do to keep this information safe. It is necessary however that the way you hash it is also an approved and secure way, so not every hashing algorithm is useful here. There are a lot of ways to do this, you should always rely on something approved, maybe even something open source so that a community can check wether its really secure or not. Usually there are security packages for every operating system that you can use that implement those things properly, you should never try to code your own stuff here in my opinion. You could check for sha-256 or sha-512 implementations for example, just to give you well known and approved algorithms that I assume often do the job.
The question I'm asking myself is why you would want to send the information back to the frontend because in most cases this should not be necessary. Once hashed in the database you should never be able to retrieve the original password anyway. If you want to verify if a user entered a correct password, you can easily check that fully on the backend side. This can be done by sending the credentials entered in the frontend to the backend (this is a security problem already which is why you should use something like ssl), then hash the password with the exact same algorithm you use to hash passwords initially and compare this hash with the hash that was saved in the database for the given user. This is a simple equals check that tells you if the credentials were correct or not and therefore telling you if the login should be successful or not. Then there is no way to send the information bsck to the frontend.
Also I'd advise to use a random string value for every new password and combine it with the password before the hashing function to create a unique string. I think this is referred to as a salt value. This way two passwords won't have the same value in the database even if they are actually the same password, which makes it more secure. When you use a salt value you have to save it as plain text in the database with the rest of the indormation though so you can use it for the equal check again later. In this case you can load the salt value of the user and combine it with an entered password again, hash it with your algorithm and check if the entered and saved hashes are equal. Both hashes should only be equal if they were generated with the same salt, password and hashing algorithm.
There is a lot more that you can do to secure this stuff, this is just a basic example of how you could achieve a relative secure login mechanism with relatively low amount of effort. It always depends on what you are trying to do, if it's a simple home stuff or maybe something for a big company and so on. If it affects a high amount of users with information that needs to be extremely secure I would recommend to use professional toolsets or services ehich specialize in exactly those kind of things.
Edit
nodejs crypto implementation
For the hashing functionality you can checkout nodejs' internal crypto service that brings a ton of functionality with it. Here's some code to give you an example of how creating a hash with a salt can look like.
var sha512 = function (password, salt) {
// create hmac instance with algorithm and salt
var hash = crypto.createHmac('sha512', salt);
// here comes the password that you want to hash
hash.update(password);
// get the hashed value
var value = hash.digest('hex');
// keep the salt for future references
return {
salt: salt,
passwordHash: value
};
};
passport authentication library
If you want to implement a real authentication you can have a look into Jared Hansons passport library. It helps you to implement all the stuff that is usually quite tricky like keeping the user logged in, making sure certain http requests are only possible if the user is logged in, keeping track of the user state or sending an authentication token to the frontend. It's still tricky to begin with, but it is still way easier than doing this on your own. Also he brings an insane amount of so called strategies with it that you can install and use, for example for oauth authentication with facebook, google, etc.
Doing a little bit of research on security and it strikes me how very insecure many of the browsers are. For example passwords are stored in plaintext if 'Remember Password' is selected on a website login, and are easily revealed if the machine is unlocked or insecure.
I was wondering for example once the session has been logged in, where is the password stored then? I realize if the connection has SSL/TLS enabled any content to and from the server is encrypted, but what about at the local computer. Is the password still kept in plaintext somewhere within the browser or does it immediately become encrypted when you login?
Websites are not that unsafe. You are confused because you are mixing 2 different things:
Your browser can save passwords of website you log in if you ask it to do so.
Here is. for instance, how you can enable this feature on Firefox by checking Remember passwords for sites option:
If you are worried about the security issues of your passwords you use to log into your favorite websites (you should), then you can use a password manager which stores your passwords encrypted on your machine.
What I mentioned above is not to mix, and has nothing to do, with the autoLogin (Remember Me) feature which could, however, have security failures depending on how it is implemented (mainly if your website's developers are enough bad to code cookies that contain your credentials).
Edit: As long as the website doesn't explicit tell the browser to save it in the cookies, it is not saved anywhere, because the browser only sends cookies to the server once you logged in. (Yes, i know there's also background information like agent etc., but that's not the topic here!)
Another exception would be a webpage that is using $_SESSION Cookies - then the browser must send it in every new session of course! But that's a completly new LogIn-Session with new Cookies every time.
OLD:
Are you talking about where you can find the password like
about:preferences#security in Firefox, where it is possible to show the password in completly plain text, or the actual physical location on the drive?
sorry for posting question in answer btw - I was not allowed to comment your question :/
I add encryped password using this command:
insert into users values ("new#emal.com",ENCRYPT("password"));
Now I have encrypted passwords in that table. Is it possible to decrypt them and if yes how? What kind of algorithm is this?
Somebody hacked something on my server and is sending mails. It looks like that the password of some old accounts was guessed. So I am trying to find out what password I had there (just changed it). So I can see what password I should stop using.
The ENCRYPT() function doesn't work on MySQL running on Windows.
On Unix-style servers it uses the crypt(3) function. This performs a one-way encryption of the text you pass it.
This is not, repeat not, a secure way to store user passwords any more. If you use this on a network-accessible web site, a cybercriminal is almost certain to pwn your users. Please read this for advice: http://php.net/manual/en/faq.passwords.php