Imagine you have a site that uses some oauth solution. In this case, you might have urls like signin.mycompany.com for login, then usecase1.mycompany.com for one use case, and so on... When you save your pwd, password managers (like the built-in solutions from Safari/Chrome/Firefox) will usually save the password under the name signin.mycompany.com ([email]) -or something similar.
If the user forgets the password or changes it, the chance that the form for the pwd change / reset are on different subdomains is relatively big. Is there any way to set the name the pwd is saved under to "mycompany.com ([email]), so that all subdomains will use and save the same entry? Or at least find some solution that will behave properly?
I know this might sound like a security vulnerability, but in such cases often sites have specific CORS policies to allow subdomains to access resources, so generalizing password manager (as long as it is controlled from serverside) should not be a big deal...
Related
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.
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'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 :/
What is the simplest way to make a page accessible by username/password? In school I learned to do this on the server side using sql and java. I'm wondering is there a way to do this only on the client side?
EDIT: lol... based on the responses, I probably should say why I specified client-side. I'm being asked to load an extra page into our company website that is supposed to aid some of our employees. I didn't design this extra page, and I was asked to put this up with a very simple log in. Granted I need to confirm with my superior that a client side login is ENOUGH, I just wanted to know if it could be done IF they decide that it's not all that important. The page itself won't have a link on the site, so unless someone knows it's there or decides to snoop, nobody will even know it's there.
You can save your page into a directory protected by .htaccess file.
That would be server side (you have to upload a .htaccess file into the directory).
But client side? Hmmmm the only thing I imagine is to create a DIV with position: fixed that would be over all your page content.
Ask for a user and a password, then check them using Javascript (this is client side), then you add property "display: none" to the DIV that is containing the login view.
That would hide the login view and show the page that is below it.
This is a HUGE security problem in my opinion. I could easily edit your web with Firebug and add Display: none to the div without entering a password.
However, as the password IS in the Javascript I could look at it anyway just viewing the source code.
The easiest is probably server side apache authentication. Use these two generators for that:
http://www.htaccesstools.com/htaccess-authentication/
http://www.htaccesstools.com/htpasswd-generator/
Just on the client side, using javascript it's never secure enough. But there is way:
if( prompt('Enter password') == 'password' )
{
// we are okay
}
else
{
// password is wrong
}
For more robust example, with username see http://jsfiddle.net/7mZYQ/2/
Well you could try a basic JavaScript dummy with HTML inputs that would somehow offer the slight illusion of password protection. Otherwise, create an HTML form and go with PHP Sessions. These are probably the languages with the most tutorials around so it wouldn't take you that long to pull it off.
You cannot do this securely only on the client side, it would require you to perform authentication of the user inside the browser. This means your whole userbase would have to be loaded in the browser memory in some form, likely in javascript which makes it unsafe.
For a simple authentication mechanism which involves the server to a minimal extent look at Basic Authentication.
No, it cannot be done on the client side. At least not in a secure manner. Client side (password ) validation is very easy to bypass, because clues (such as the password and/or the content you want to show when the correct password is entered) are given to the user.
If you think about what "client-side" means, you'll understand why it wouldn't be possible. On the client side, all information is processed and all data is stored on the client's machine. Thus, in order to check passwords totally on the client side, you'd have to have the entire list of usernames passwords saved to every single computer that your site interacts with.
Keep in mind, also, that anything "client side" is inherently less secure than it would be server-side. So even if you could do this, it'd probably be a bad idea.
Now, that being said, here's how you could do it:
Come up with a password (note that you'll have to use a master password, not individual ones), hash the password, and store the hashed password in a variable, or something. It may sound insecure, but if you're hashing the pw, you could send everyone a personalized email with the password and it wouldn't make it any easier to hack. Hashing is a one-way operation. There is no way to reverse engineer it. Do make sure to make your stored password a constant, though, or someone could just change the value of their hashed password last minute to match your stored one. Give the css rule Display:none; to your data with css so that it hides. Now prompt the user for a password. Then, take that password and run it through the same encryption as you did when you created the password. If that value and the one you stored match, bingo. Just revert your display:none; and you're good to go.
Though I guess that still leaves the problem of somebody just firebugging your display:none away. Guess you'd have to encrypt the data on the page too.