48

Is 2FA via mobile the best security there is? No. SMS 2FA is the weakest form of 2FA, however, it's still worthwhile because it does improve security and it has a relatively low barrier of entry especially for non-technical users. What can be improved? You can use TOTP token using apps like Google Authenticator. This still uses your mobile phone, but it ...


41

once A gets falsely authenticated as B... On any minimally secure system, this isn't how it happens. From the system's point of view, User B is authenticating himself, not User A. It was not falsely authenticated, it was using the real login and password. It's simple case of Credential Theft. You could harden the system using any form of 2FA, but the system ...


26

SMS 2FA is not only a bad idea; it's worse than not having 2FA at all (password only). This is because virtually all services offering "SMS 2FA" are actually delivering SMS 1FA! That is, they allow full account recovery via SMS, with no need to have the account password. This means anyone who can: convince your mobile carrier to port your number convince ...


8

Authorization and Authentication are two sides of the same coin where authorization is sometimes dependent on authentication but not always. How? Even without a login , a visitor to Stack Exchange can view questions and answers. Here the visitor has authorization to view answers but surely doesn't need authentication for that, hence here authorization is ...


6

Generally speaking, it's a good idea to consider all the four As (Authentication, Authorization/Access Control, Accounting, Auditing) rather than just two. There is no method of authentication that can reliably counter the $5 wrench method (as described by the webcomic XKCD, that's where you hit someone with a $5 wrench until they log in for you) although ...


3

First of all, let me say that your scenario is quite bad. Storing copies of personal information on an unsecured laptop that people could rob rings a number of bells, and my first instinct would be to ask why do you really need to do that?? It may be possible to handle it on a better way. And even if budget restrictions are a concern, do note that they need ...


2

Could I query your "Solution for 1st problem": Solution for 1st problem: Both Desktop App and API share a Secret Key that the API will use to generate the JWT and the Desktop App will use to verify this JWT. The way you're implemented this now - if somebody recovers your secret from the desktop app, they could use this to create a new JWT token that both ...


2

I don't think there is a big difference in security between cookies or headers, if properly used. Cookies are meant to maintain server state. So if you have a login call which starts a session, cookies make sense. If you use an API token that is distributed outside of the API, cookies don't make sense. In the end, cookies are also sent in headers, so there ...


2

It depends on what you compare to, what you have to protect and what your users can be billed and trained to use. 2FA with mobile phone is prone to phone theft, phone malware, phone operator's SIM replacement (mis-)procedures, mobile net vulnerabilities and so on. It is, however, WAY better than 1FA of, say, user password. So it makes a good step at ...


2

Another thing to consider also is that the assumption the OP is making: "once A gets falsely authenticated as B, A gets all the access privileges of B." is not necessarily correct in all systems and use cases. For example, in a system with a dual control workflow, I have to authenticate first but then also be granted a permission to a specific resource from ...


2

An authentication token needs to be unguessable. Some UUID's are, some are not. If you go with a UUID v. 4 that is generated with a CSPRNG you should be fine. It has to be cryptographically secure, though! Another option, since I hope you already have TLS in place, would be to use client certificates.


2

Authentication against a local JS application does not work. I wrote a detailed answer on this topic before. The crux of the argument is that an attacker is in complete control over the mechanism that performs the authentication, and is therefore able to always authenticate themselves successfully. What about Multi-Factor Authentication? It will not fare ...


2

Password complexity is not just for brute-force attempts on the account login, which 2FA would help mitigate. But password complexity also protects against the situation when the password hash database leaks. 2FA only helps if 2FA is turned on and enforced. If you have the option to "authorise" a device, then all the user has for protection is the shorter ...


1

Timing step 2 does leak information. In order for it not to, you'd need a database implementation where hits and misses take the same amount of time. It is probably more important, though, that you run step 3 unconditionally. If a username is not in the database, then use a dummy value for the salt and execute your password hash using the same configuration ...


1

Likely (almost?) any framework which does not stop executing the code after the Location header is sent behaves that way. It is perfectly fine from the perspective of HTTP that a response with a location header also has a HTTP body. It is also perfectly normal that the web application might need to do more processing even after issuing the redirect. So, ...


1

Okay! Caveat emptor, first off: I’m a rando on the internet, don’t make decisions off this, YMMV, etc. With that out of the way this seems pretty much fine to me. Nothing seems out of the ordinary here. The main thing I’d check is securing the secondary endpoints, like /refresh. Make sure that one can’t be fiddled with, for instance. And make sure you test ...


1

I'm the author of the blog post you referenced, as well as the answer to the SO question you linked. Here are the answers you are looking for. A session ID is an opaque reference to actual session data stored on the server. It is safe insofar as it is random enough to not be guessed easily, and the data is safe because it is not directly accessible ...


1

To me, the simplest explanation is as follows: Authentication tells the system who you are. Authorization tells the system what you can do. If client A got the login and password of B and managed to authenticate as B, for all intents and purposes to the "fooled" server, A is now B and is authorized to do whatever B can do. Although authorization works ...


1

Authentication answers this question: Are you who you say you are? Numerous ways to do this, but how is irrelevant. Some ways are obviously more effective or reliable than others. You can also look at it as two questions: Who are you? How can I be sure? Authorization answers one of these questions: What are you allowed to do? Are you allowed to do X? ...


1

Your question does highlight the need for robust authentication mechanisms, and the reason why many for some time have considered the password a 'dead' control. Further this is the reason multi-factor authentication is gaining adoption. Let's spin your question around though: Suppose an org has a system that hosts financial HR, administrative, and other ...


1

Your first concern is a very real one, services who don't understand that sometimes, some customers may have no access to text messages – these services are wrong. However, having other software running on your phone is not the worst concern regarding 2FA via SMS. OK, some bad actor will read a one-time 6-digit authorization token. They cannot reliably ...


1

Yes, you can use a proxy. Your two questions will answer with one application, you need to set up this. You can use NGINX. NGINX is opensource software for web serving, reverse proxying, caching, load balancing, media streaming, and more. Here's my answer to your questions: Yes you can use nginx proxy to protect your admin panel, Here's the link https://...


1

I would suggest alternative - that I encountered in one OAuth server implementation. Instead of requiring clients to provide all refresh tokens for invalidation simply store logout record for some time. The logout record would contain user identification, client identification and logout timestamp. Your server do not need to know all invalid tokens, ...


1

as far as my experience goes, this is not possible in a pure windows environment. you can workaround this however by using a credential vault like thycotic secret server or a competitor. have all admin credentials inside the vault, with random passwords so the real person doesn't know the password, and therefore has to use the credential vault to initiate ...


1

The only reason I can imagine for using that scheme is to avoid using 2 key pairs due to technical reasons (for example, not enough available space in the memory system seams reasonable to me for an infotainment system). If that's the case I suggest using a symmetric cryptographic algorithm with its corresponding secret key since it looks like you only need ...


1

Access control needs to be done server side, not client side. The moment you send the data to the client, it is game over. It can now be read by the user, no matter what your SPA looks like. The content can still be taken from the HTTP requests, from JS variables, local storage, or wherever you put it. You'll need to have a backend API that only serves the ...


1

Yes, 6 months is indeed a very long time because if the token gets stolen by an unauthorised third party, that party would be able to use the token for a very long time (unless detected). This is not very secure. As you said, a slightly more secure way to do it is just as you mentioned - use refresh tokens. The way this works is that you’d have two tokens -...


1

SSH2 does public key authentication based on RFC4252. According to RFC4252, section 7, the client uses its private key to create a signature over the following data: string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string public key algorithm ...


Only top voted, non community-wiki answers of a minimum length are eligible