Tag Info

New answers tagged

1

First off, as you probably know, OpenID Connect is just an authentication layer built on top of OAuth2. So regardless of which on you pick, you will need to implement OAuth2 (as the common denominator). OAuth2 itself is an authorization mechanism (i.e. allows you to check that a token is valid and has a specific set of scopes granted). It does not provide ...


1

From what you have explained it seems that OAuth 2.0 would better suit your needs. OpenID Connect was developed to add secure authentication to OAuth 2.0. Large providers i.e. Google, Facebook, Yahoo, etc began using OAuth 2.0 as a way to authenticate users with "login with" services so users could use their credentials to authenticate to a variety of ...


1

Yes stealing a stored OAuth token from a device and using it to make requests as the user will definitely work. OAuth access tokens are analogous to a traditional session cookie used in a web application. It might help if you're familiar with pre-http-only flag cross-site scripting vulnerabilities were an attacker would exploit a cross-site scripting ...


0

From http://oauthlib.readthedocs.org/en/latest/oauth2/clients/mobileapplicationclient.html: The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and ...


3

I would personally do 3 things in this situation: Show the client the data on the percentage of major breaches that are a result of phishing (Something like 95-97%) Further show that phishing can directly lead to an attacker to sniffing traffic on the network and he/she can view every bit of data passing to and from those services. Identify the quantity ...


0

Based on Justin's answer, I'm constructing my own. If the tokens are long enough (in my case they are 200 alphanumeric ([A-Za-z0-9]) characters, there is no need to salt them. Hashing alone should then be enough, since the complexity is high enough. If tokens are not long enough to get away with hashing only (or if you want to insist on salting them as ...


2

There will eventually be a case where an action that is perfectly authorized at the proxy level will be able to cause unexpected behavior in a backend component. It's a matter of when, not if. This is a terrible idea. Your instincts on this are correct. Do anything you can to convince your client that they should not proceed down this path.


6

Based on my understanding, I think you don't even need to get inside the internal network to prove that's it's a terrible idea. An attacker (who can be an ex-employee, third party contractor or an existing disgruntled employee) having some context about this insecure internal application, including details such as internal host address where the application ...


5

This is how a approach your situation in general. Speak to the business There are three things that I think clients can really relate to when discussing the security of their applications. (90% of the time the users are a footnote). IP (Intellectual Property). No customer want their secrets available to their competition. Image. Companies can be kindly ...


2

The most common cyberattacks are summarized very well in the annual Verizon Breach Report: http://www.verizonenterprise.com/DBIR/ As can be read therein, phishing and credential theft attacks are two of the most common threats. Thus, if an internal system is compromised by someone accidentally clicking on a malicious link, an attacker is now inside the ...


1

If requests from the third party to the OAuth provider have some other data that associates the request to the user, for example the user's name or id, the server could store the bearer token like a regular password with individual salts. However, if the third party requests don't have a piece of identifiable information, the server could store a ...


5

An internal user with a browser that also connects to the outside provides routes between the intranet and the public internet. I'm constantly pointing this out to people who tell me, "don't worry this is an internal web app". HTTPS is necessary in your case. This not only protects against the threat you mention, someone who has broken into the network, ...


1

This sounds different from what I've heard about previously. My understanding of a typical microservice architecture is that you'd have a variety of fine-grained microservices, composited together into one or more coarse-grained applications. In that view, you would probably have a single E-Commerce Web App, which utilizes a variety of microservices in the ...


1

This is actually not that uncommon a setup. Typically where an application uses stateless cookies, there's no way apart from timeout to invalidate the session. The advantage of this appraoch is that the server doesn't need to maintain a list of valid cookies, which is handy for scaling, the downside is (as you've noticed) if the application has a long ...



Top 50 recent answers are included