[keycloak-dev] Adaptive risk login

[Stian Thorgersen]

On 29 August 2016 at 16:41, Marc Boorshtein <
marc.boorshtein at tremolosecurity.com> wrote:

> >
> > VPNs are certainly not the solution in all cases as more and more
> > applications are exposed directly on the Internet everyday.
>
> Very true (as are all your other statements) but my point about VPNs
> wasn't that more people are using VPNs as a way to protect
> applications (probably the opposite).  Its that VPNs can be easily
> used to bypass many of the features of adaptive authentication.  Most
> adaptive deployments I've seen rely on geo location mappings of IP
> ranges to determine where users are logging in from.  Use an OpenVPN
> into a Amazon/Google/Azure/Pick-Your-Favorite-Proider network and out
> to the internet and that feature becomes useless.
>

Yep, that's an issue. There's also bot farms as well. Not many people will
issue an attack from their home address.

Still has some level of protection. For example VPNs are costly, tend to be
rate limited.


>
> Looking at the list Thomas provided, 6 of them can easily be spoofed
> or circumvented:
>
> VPNs from a private server in the cloud would circumvent these
> - IP Address Range - ip IP not in IP range raise risk
> - IP Address History - if IP not in IP address history raise risk
>

History wouldn't be that easy to spoof. However, loads of people have
dynamic IP addresses so it would end up raising the risk for legitimate
users.


> - GeoLocation - if IP geolocation based on
> http://www.maxmind.com/app/country is not from a certain area raise
> risk
>

The IP address of a large portion of attacks still come from certain
regions, so it does provide some level of protection even though it can be
circumvented.


>
> And these can be bypassed by a browser plugin:
> - Known cookie - if a certain cookie + value not present raise risk
> - Device cookie - if not a known or trusted device raise risk
>

Not if the value is associated with the user and signed with the realm keys.


> - RequestHeader - if certain request header is not present raise risk
>
> (additionally, many enterprises deploy GPOs that clear persistent
> cookies, which is how a device cookie is implemented)


> While these are certainly only examples of rules that can be used,
> most of the really interesting rules requires a considerable amount of
> data and analysis to be useful. That data needs to be kept up-to-date
> as does the analysis.
>

It does depend on what level of protection you are looking for. If it's for
a web application and you're trying to block out script kiddies and other
people looking for easy targets the rules doesn't have to be that complex.


>
> I'd amend your statement on layered security to be "effective" layered
> security.  If someone is trusting a security mechanism that either
> isn't kept updated as needed or is not providing the expected security
> becomes a liability.  I've seen plenty of examples of folks relying on
> a security mechanism that didn't supply nearly the security they
> thought it did and it didn't work out too well.
>

Definitively true - there's some serious false sense of security in
implementing random security defenses that have no real level of protection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160829/f70fd528/attachment.html