A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.

New answers tagged

0

According to this, it is possible but not secure or recommended to ask the user for a password in a custom login screen, what I can understand. The main reason for that being frowned upon is because you don't want users to get in the habit of typing in their passwords anywhere other than their respective websites.A malicious website could ask for your ...


3

You are mixing the concepts of authentication and authorization. The first is to know who the client is and the second to decide what this client can do. A client certificate in TLS is just used for authentication, i.e. like username + password but only better. If the service you want to access will accept this certificate as authorized is fully up to this ...


2

Your mobile app is the "client application", and the API that makes the client app function is the "resource server" (the "resource owner" is normally the person using the app). The use of PKCE here protects against an attacker intercepting the authorization code, which can be relatively easy on mobile apps if custom URI schemes are used. Like you say, ...


3

It sounds like you've got two problems that you're kinda rolling into one: Device enrollment -- you need some way to know which user to register this device to, that's where the email or the phone number comes in. A valid user can register any device they want, as long as you can track the device somehow. Fingerprint the device -- on subsequent logins, ...


1

One way to protect against timing attacks when querying an indexed database field, would be to hash the value server-side. It's similar to how an attacker can't login if they obtained hashes of a password because the server still applies the hash before checking the database. The original code (from the question above) has a number of issues, as marstato's ...


2

Clarifying Assumptions I've asked some clarifying questions in comments. I'll answer assuming the following: Traffic within your backend is plaintext (ie no TLS). The API key is sent in plaintext in the basic auth field, and hashing is performed by the server only in order to compare against the stored value. Hashing and Salt I fully agree with this ...


0

The main implication is what you said, an attacker with physical access has full access to everything on the PC and your Microsoft account. For security-relevant operation on your Microsoft account, MS still asks for the password, so the most important operations (like changing password or email) can not be done via auto-login alone. If do you have a ...


1

You could do both, you hash it at the client so if the attacker can get through the https security they will not be able to see the plain text password. Then hash it again at the server so if the attacker gets the passwords stored in the server he can not just send that to the server and gain access to the password.


3

TLS provides authentication with the use of certificates on its own. TLS actually can do a number of things, but is most commonly used for establishing an encrypted session/tunnel between two end points. It certainly can be used to provide authentication, but many of the EAP protocols that do make use of TLS only do so to encrypt the traffic between ...


2

TLS can provide mutual authentication with the use of public-key certificates. However, it is not necessary to use public-key certificates with TLS for authentication. TLS can be used solely to provide encryption (data integrity & privacy) for the data being transferred on the wire, without user authentication mechanisms. Often in TLS scenarios, only the ...


4

This already exists. OpenPGP has "authentication" as a possible key usage, and a PGP key can be used to authenticate an SSH session if gpg-agent is used in ssh-agent mode. I use that daily as a single-sign-on solution with a smartcard, but there is no reason why this wouldn't work with a regular key. There are also various plugins that allow signing ...


5

An alternative approach that implements the same concepts is SRP. Ignoring the math in the protocol, the idea is that when a user signs up the client generates a password verifier which is sufficient to verify credentials, but not to act as them and sends it to the server to store. At login time the parties then exchange messages based on random values that ...


4

While the scheme described in the question has a significant problem in enabling offline bruteforce attacks against the password, it is possible to redesign it without this vulnerability. For example, one can generate private key directly from password. That avoids the need of storing the private keys at all - basically the password becomes the private key. ...


4

TL;DR: You need to give openssl verify the intermediate certificate, too. Your manual verification: $ openssl verify -CAfile /tmp/google_root.pem /tmp/server_certs.crt Does not specify the intermediate cert. When you perform the verification using s_client, it shows that there are three certs - root, intermediate, and server. I've indented your output ...


11

As the others said, private keys aren't shared. full stop. Otherwise, they are called public keys. But: Cryptographically signing on is pretty standard. HTTPS supports that: Authentication using HTTPS client certificates; and all modern browsers have the built-in means to generate the necessary keys when asked to. Your problem has already been solved; ...


66

You should never try to secure a "real" web application with a scheme that you invented on your own. As such we shouldn't discuss practicalities on how you would actually implement or use such a method. Will it work? Your scheme does not send a password over the wire. What immediately jumps out is that you send the private key to the server, which never ...


5

As Anonymous said, the private key must always be private. Sending the private key to any entity negates any security provided by your login. Basically, what you are designing is called Challenge Response Authentication, and can be done even without a keypair: One party (the server) generates a random token and sends it to the other The other (the client) ...


-3

Also, if the attacker didn't gain control of the account, why use it to enroll in all these services? First of all, some of the spam you are getting might actually be phishing attempts to lure you into revealing your password. Second reason, and maybe the most obvious: since all those sign-in attempts generate security notifications, the hacker obviously ...


9

While I like the idea of PGP for login, this is not the way it's supposed to work. The private key should remain on the client side, always, and never be shared with anyone. This setup encourages bad practices and provide incorrect education about PGP. What you could do is, have users upload their public key to the server, and then you present them a ...


6

The use of your email to sign up for services might be a coincidence and not being done by the party who logged into your account. I get a dozen of these types of "mistakes" a week from around the world due to my fairly generic email account. So, this set of events might not relate to the person who logged in. However, there are a couple of scenarios that ...


0

How to hide the username The above answers are great, but I want to add in one more simple option. Most CI providers also have a way of storing "variables" that you can reference in your build scripts. To pick a real world example, bitbucket has "variables" and you can configure them at a few levels (for instance, at the repository level or the branch ...


1

You can avoid setting the username there, moving it to the sh config. On your .ssh/config file place: Host example.com User my-ssh-user And use just example.com above. Moreover, you can even use a different name as an alias, such as blogmachine: Host blogmachine User my-ssh-user HostName example.com and it would actually connect to example.com


2

As far as I am aware, MFA only protects your login to the GMail web mail service. If the attacker could successfully guess your password and you have IMAP client access enabled on your GMail account, he would still have had access to your emails up to the time where you changed the password. You should definitely review those access settings, check the trash ...


0

You could try to mimic Certificate Revocation Lists. That means that each member of the network could publish its public key on a site they manage. But as you have no global authority, I cannot imagine a way to certify the current public key. Said differently, if an attacker manages to hack the site displaying the public key, they could impersonate the user ...


96

Should I be concerned about this? Yes. This should be of concern to you because an attacker was able to obtain the valid password for your Gmail account. From the details of warning you have provided, it looks like it is from fraud detection rather than an OTP failure. If it was an OTP failure, you would have received an OTP when that login attempt was ...


3

You shouldn't be concerned. Just as you said yourself, the attacker was blocked and you have changed the password. There are, however, some actions you should take: Verify that the discovered password does not hint at any other password you may have used anywhere else. Harden passwords of other accounts you hold that the attacker may deduce from the ...


0

From a security point of view, both have their own issues and both have their advantages. Both can be made more or less equally secure. If you use a login-page per service, you might want to synchronize passwords, using, as an example, LDAP or something like that. Otherwise, users may need different passwords per site/service. On the other hand, if you do ...


0

The part you described seems sound. Nothing blaringly wrong I see. Many things are unspecified: You didn't mention how the authentication is done, how communication is done, how signing is done. How does the client request the token, could a MITM request more tokens on behalf of the client? How are servers authenticated? How is the authentication server ...


2

It does not defeat 2FA. If someone steals only your password, or if you use the same password everywhere and it leaks, the second factor will still protect your account. That's the purpose of 2FA: add another layer of security. Having both on the same device does not change that. That "one-password-for-everything" is still secured by 2FA anyway.


1

This is an interesting problem. I would expect that in most cases the user does not remember that they had created a "real" (locally managed) account or that they want to switch to single-sign-on using their Google account. I don't really see this as a potential attack vector since the attacker would need to have access to the Google account already which ...


1

Congratulations! You have just given a nice example that different applications with different security requirements use different approaches. The highest requirements for whatsapp are availability and ease of use because they are targetting end users and assume that they can trade a light confidentiality risk (do not ask password on each new session) for ...


0

This is exactly the problem that hardware security modules (HSM's) aim to solve. An HSM has its own embedded processor, and contains one or more private keys, which never leave the HSM. Hence, the private keys on the HSM are inaccessible to programs running on the machine that the HSM is connected to. The HSM can be used to authenticate with a server, ...


3

no matter how I handle the api["secret"] it ends up on RAM which can be dumped by malware and uploaded to an attacker. ... How can this be avoided? It can't be. There is a fundamental contradiction between the requirement to use the password for a computer-based authentication step, and yet to want the computer not to have access to the ...


1

This is exactly the problem that protocols like PAKE and SRP aim to solve. With PAKE/SRP, the client and the server mutually authenticate each other based on a password known to both the client and the server. The client demonstrates to the server that it knows the password, without the client sending the password (or password-equivalent data) to the ...


0

You have mainly a session management rather than an authentication issue. As you noted, users are already authenticated, what you have to decide on is how to maintain the user's session. Issuing a JWT upon Google atuhentication is reasonable choice albeit with non-trivial caveats as a quick search will demonstrate. Instead of a JWT you could rely on HTTP ...


-2

Unfortunately the days of a simple application Authentication and Authorization are gone. Authentication or trusting of just the end-user and not the server is the basis of Man-in-the-middle attacks. In today's threat environment there are no simple "safe" methods. There are three current Web Authentication and Authorization specifications that are proven ...


3

For example, hashing the password and the challenge together and sending it back to the server. The server would do the same with the user's stored password and check if both values are the same. In this scenario, the server would need to have the user's complete password, stored in plaintext or encrypted form. This introduces a security risk - if your ...


0

So your goal is to be able to immediately invalidate a user's token, without needing a db. Like you say in comments, this is not really possible. I'm don't think your design accomplishes this. My understanding of your design is that instead of recording in the db when a user becomes invalid, you will send them back a token which marks them as invalid, ...


1

As far as I can see from the respective websites those apps are specific to one service. I am not aware of a generic "push" protocol. So if you want to get that form of push notification from a service you will have to install the matching app.


1

AFAIK (As far as I know) that's what distinguishes the confidential from the non-confidential flow: the confidential flow requires the client_secret whereas the non-confidential doesn't. Rather than the flow itself, it's the client that distinguishes confidential from non-confidential (I've seen it more commonly referred to as public.) Confidential ...


1

I fully agree with your analysis that such a proof is impossible with common websites: The private key of the server is only relevant inside the TLS handshake and can be used to prove that a specific TLS handshake was done with a specific endpoint with a specific key pair. After the handshake the transferred data get encrypted and integrity protected. The ...


0

If the underlying crypto system is solid, it does not really matter if you use a timestamp, a counter, or a random number. If the backend is well written, the key cannot be determined even if the attacker knows the public key, the cyphertext AND the cleartext. If your backend uses AES, this is not you should care about. An attacker will not be able to ...


0

I do not see the problem in authentication it's more authorization. Legit solution is to enforce networking rules with iptables so any traffic besides api gateway is not allowed only from api gateway. One of security rules is to take care of attack vectors which in your case is api gateway. For more security you should check business logic on api gateway ...


1

In your php script, you can use logic like the following to check if the user is authenticated, then send the file in the response only in this case. As you can see, the script first sets the appropriate response headers for the filename and content type, then uses the php readfile() function to output the file. This way, you can store the file in a ...


Top 50 recent answers are included