6:55 a.m.
Hello group,
I just add a look at a nice feature from Forge Rock AM called:
"Adaptive risk login".
From the book "Open Source Identity Management Patterns using
OpenAM 10.x":
"Adaptive Risk authentication allows OpenAM to determine the
risk of a
particular
authentication, and decide whether additional authentication steps are
required due
to the risk."
"The Adaptive Risk module has a risk threshold that is set manually, and by
default
is set to 1 . There are a variety of different authentication risks which
are each
given a score. If the value of the score meets or exceeds the risk
threshold, then the
authentication fails."
- Risk Threshold exceeded - if inherent risk for a particular (client
login) exceeds theshold
- Failed Authentications - if user had failed authentications recently
raise risk
- IP Address Range - ip IP not in IP range raise risk
- IP Address History - if IP not in IP address history raise risk
- Known cookie - if a certain cookie + value not present raise risk
- Device cookie - if not a known or trusted device raise risk
- Time since last login - if last login > x days raise risk
- Profile attribute - if a profile (user) attribute is set raise risk
- GeoLocation - if IP geolocation based on
http://www.maxmind.com/app/country is not from a certain area raise risk
- RequestHeader - if certain request header is not present raise risk
These checks can be combined / inverted which provides one with a flexible
system to specify rules.
I think a functionality like that would be great addition to Keycloak. Some
of this
functionality is already partially possible with Keycloak but only for some
authenticators.
Would be great to have more general support in that regard.
Cheers,
Thomas
7:32 a.m.
On Aug 28, 2016 7:56 AM, "Thomas Darimont"
<thomas.darimont(a)googlemail.com>
wrote:
Hello group,
I just add a look at a nice feature from Forge Rock AM called:
"Adaptive risk login".
Adaptive risk was really popular around 2010 as a multi-factor without a
token. Mainly banks didnt want to hand out rsa secureid tokens. They used a
bunch of factors like your flash version, source IP, etc. It turned out to
be more trouble then it's worth. Between the ease of creating soft tokens
like totp and the popularity of VPNs the adaptive risk approach proved to
be mostly pointless. The amount of statistical data needed to make these
decisions useful, and the amount of skill needed to configure was
outweighed by simpler multi factor implementations.
Oracles adaptive access manager, the most notable enterprise adaptive
access manager, was merged into Oracle access manager mainly for the couple
of alternative login methods but the adaptive part has disappeared. My
guess is this was a "me too"/checkbox feature. I've done several forgerock
implementations and this comes up as a theoretical discussion but never
goes beyond that.
I've seen a few machine learning based approaches to authentication but
they go well beyond tracking a risk score, more behavior tracking stuff.
The couple I've seen end up integrating via saml or oidc anyways so there
wouldn't be much to do on the kc side.
8:48 a.m.
Doesn't seem adapter authentication is dead:
https://www.google.no/?ion=1&espv=2#q=adaptive+authentication&tbm...
VPNs are certainly not the solution in all cases as more and more
applications are exposed directly on the Internet everyday. Two factor is
certainly improving security ten folds, but there's also issues with those.
A token can be lost or compromised. There's needs for password recovery.
End of the day the more layers of security you have the less likely you'll
get compromised. VPNs + two factor + adaptive authentication might just
combined be enough to give you the level you need.
We do have adaptive authentication on the radar for Keycloak. There's a
fairly good chance it's something we'll look into for 3.x (2017). As such
I'd love to hear more what others think about it.
On 28 August 2016 at 14:32, Marc Boorshtein <
marc.boorshtein(a)tremolosecurity.com> wrote:
On Aug 28, 2016 7:56 AM, "Thomas Darimont"
<thomas.darimont(a)googlemail.com>
wrote:
>
> Hello group,
>
> I just add a look at a nice feature from Forge Rock AM called:
> "Adaptive risk login".
Adaptive risk was really popular around 2010 as a multi-factor without a
token. Mainly banks didnt want to hand out rsa secureid tokens. They used a
bunch of factors like your flash version, source IP, etc. It turned out to
be more trouble then it's worth. Between the ease of creating soft tokens
like totp and the popularity of VPNs the adaptive risk approach proved to
be mostly pointless. The amount of statistical data needed to make these
decisions useful, and the amount of skill needed to configure was
outweighed by simpler multi factor implementations.
Oracles adaptive access manager, the most notable enterprise adaptive
access manager, was merged into Oracle access manager mainly for the couple
of alternative login methods but the adaptive part has disappeared. My
guess is this was a "me too"/checkbox feature. I've done several forgerock
implementations and this comes up as a theoretical discussion but never
goes beyond that.
I've seen a few machine learning based approaches to authentication but
they go well beyond tracking a risk score, more behavior tracking stuff.
The couple I've seen end up integrating via saml or oidc anyways so there
wouldn't be much to do on the kc side.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:36 a.m.
+1.
Adaptive security by itself is not something trivial and it usually implies some complex
event processing, analytics and integration with different sources of information.
Considering that today we need to consider a very heterogeneous environment, where users
are distributed across different regions, with different local policies, using different
devices and with a high demand for information sharing,
adaptive security plays an important role at this regard.
We can extend this functionality not only to authentication/login but also to when
authorizing access to protected resources.
----- Original Message -----
From: "Stian Thorgersen" <sthorger(a)redhat.com>
To: "Marc Boorshtein" <marc.boorshtein(a)tremolosecurity.com>
Cc: "keycloak-dev" <keycloak-dev(a)lists.jboss.org>
Sent: Monday, August 29, 2016 10:48:10 AM
Subject: Re: [keycloak-dev] Adaptive risk login
Doesn't seem adapter authentication is dead:
https://www.google.no/?ion=1&espv=2#q=adaptive+authentication&tbm...
VPNs are certainly not the solution in all cases as more and more applications are exposed
directly on the Internet everyday. Two factor is certainly improving security ten folds,
but there's also issues with those. A token can be lost or compromised. There's
needs for password recovery.
End of the day the more layers of security you have the less likely you'll get
compromised. VPNs + two factor + adaptive authentication might just combined be enough to
give you the level you need.
We do have adaptive authentication on the radar for Keycloak. There's a fairly good
chance it's something we'll look into for 3.x (2017). As such I'd love to hear
more what others think about it.
On 28 August 2016 at 14:32, Marc Boorshtein < marc.boorshtein(a)tremolosecurity.com >
wrote:
On Aug 28, 2016 7:56 AM, "Thomas Darimont" < thomas.darimont(a)googlemail.com
> wrote:
Hello group,
I just add a look at a nice feature from Forge Rock AM called:
"Adaptive risk login".
Adaptive risk was really popular around 2010 as a multi-factor without a token. Mainly
banks didnt want to hand out rsa secureid tokens. They used a bunch of factors like your
flash version, source IP, etc. It turned out to be more trouble then it's worth.
Between the ease of creating soft tokens like totp and the popularity of VPNs the adaptive
risk approach proved to be mostly pointless. The amount of statistical data needed to make
these decisions useful, and the amount of skill needed to configure was outweighed by
simpler multi factor implementations.
Oracles adaptive access manager, the most notable enterprise adaptive access manager, was
merged into Oracle access manager mainly for the couple of alternative login methods but
the adaptive part has disappeared. My guess is this was a "me too"/checkbox
feature. I've done several forgerock implementations and this comes up as a
theoretical discussion but never goes beyond that.
I've seen a few machine learning based approaches to authentication but they go well
beyond tracking a risk score, more behavior tracking stuff. The couple I've seen end
up integrating via saml or oidc anyways so there wouldn't be much to do on the kc
side.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:41 a.m.
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.
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
- GeoLocation - if IP geolocation based on
http://www.maxmind.com/app/country is not from a certain area raise
risk
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
- 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.
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.
11:34 a.m.
On 29 August 2016 at 16:41, Marc Boorshtein <
marc.boorshtein(a)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.
12:06 p.m.
> >
> > 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.
If you're talking about a DDoS or script kiddies just running massive
sets of scripts against a target, sure but I don't think KC (or any
authentication system) will be what stops that. That'll be a
combination of network infrastructure and web application firewalls
screening out specific exploits. Where the value of adaptive auth
would I think be more likely is a targeted attack with a known set of
credentials where a set of actors is trying to leverage something they
have to get elevated privileges. In which case getting a single
openvpn running on an aws account could cost as little as a few
dollars and circumvent many of the risk barometers based on source ip.
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.
Sure, but I don't think KC (or any authentication system) is going to
stop a script kiddie. The vulnerabilities they are generally going
after are known exploits that haven't been patched and don't require
authentication. Just watch the logs for a known wordpress site and
you won't see any requests for authentication from trollers (unless
its with a specific exploit). You'll see reams of trying to hit
wp-admin with known exploits to bypass authentication all-together.
Even looking at the articles mentioned, everything is theoretical.
Adaptive authentication has been around for at least 8-10 years, you'd
think if it were used to great success there would be more success
stories rather then theories. The new part they point out is the
addition of machine learning to the process to make more intelligent
decisions, which makes sense. Something like Google's new captcha
system. KC would make a great integration tool for something like
that.
ps: great conversation, really enjoy these types of discussions
4:31 a.m.
On 29 August 2016 at 19:06, Marc Boorshtein <
marc.boorshtein(a)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.
If you're talking about a DDoS or script kiddies just running massive
sets of scripts against a target, sure but I don't think KC (or any
authentication system) will be what stops that. That'll be a
combination of network infrastructure and web application firewalls
screening out specific exploits. Where the value of adaptive auth
would I think be more likely is a targeted attack with a known set of
credentials where a set of actors is trying to leverage something they
have to get elevated privileges. In which case getting a single
openvpn running on an aws account could cost as little as a few
dollars and circumvent many of the risk barometers based on source ip.
>
>
> 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.
>
Sure, but I don't think KC (or any authentication system) is going to
stop a script kiddie. The vulnerabilities they are generally going
after are known exploits that haven't been patched and don't require
authentication. Just watch the logs for a known wordpress site and
you won't see any requests for authentication from trollers (unless
its with a specific exploit). You'll see reams of trying to hit
wp-admin with known exploits to bypass authentication all-together.
It's certainly not going to stop attacks going after known exploits. The
only real defense against that is limiting what's exposed and making sure
everything that is exposed always has the latest security patches. The
latter being one good reason for using a supported product rather than a
community project as you are able to get patches to older versions as well
as retrieve patches prior to the vulnerabilities being made public.
Adaptive authentication could for instance stop someone trying to use
common passwords with a list of known usernames. We have a rather naive
brute force protection in Keycloak that prevents that to some degree, but
it's far from sophisticated enough. For example it prevents many guesses to
one user, but not few guesses to many users. However, that would more
likely be the job of a intrusion detection system and firewalls to stop
those type of attacks in either case.
Even looking at the articles mentioned, everything is theoretical.
Adaptive authentication has been around for at least 8-10 years, you'd
think if it were used to great success there would be more success
stories rather then theories. The new part they point out is the
addition of machine learning to the process to make more intelligent
decisions, which makes sense. Something like Google's new captcha
system. KC would make a great integration tool for something like
that.
You're right. Simple rules like an IP range are just not going to cut it.
Much more complex and intelligent processing of data is required. If the
rules are to defensive you also end up blocking legitimate users. In which
case you need a way for the legitimate user to prove they are who they say
you are. In which case you can send a mail or even use Google's reCAPTCHA.
Even sending an email when you've detected a login from a new machine is
useful to at least detect malicious access.
One thing we should at least do is to add a device cookie which includes
the user-id that is signed with the realm key. This would allow us to
identify a device that has been used before. If we detect a new device we
can introduce options such as send an email to verify the device, display a
reCAPTCHA or even simply send an email to the user to notify about the
login.
ps: great conversation, really enjoy these types of discussions
+1000
1:22 a.m.
user(s) attached device cookies will definitive add a lot of value to KC.
Simple enough to handle.
+1
Best regards
Mit freundlichen Grüßen
Cordialement
Francis Pouatcha
Founder and Technical Lead Group Adorsys
LinkedIn: http://www.linkedin.com/pub/francis-pouatcha/8/35a/542
adorsys GmbH & Co. KG, Germany:
http://www.youtube.com/watch?v=rVRkFGUNexo&authuser=0
Adorsys S.A., Cameroon: "African Software Competence Center"
Open https://github.com/adorsys
Cell USA: +1 770 329 7026
Cell Germany: +49 172 18 16 074
Cell Cameroon: +237 51 74 71 99
On Tue, Aug 30, 2016 at 11:31 AM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
On 29 August 2016 at 19:06, Marc Boorshtein <marc.boorshtein@
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.
>
> If you're talking about a DDoS or script kiddies just running massive
> sets of scripts against a target, sure but I don't think KC (or any
> authentication system) will be what stops that. That'll be a
> combination of network infrastructure and web application firewalls
> screening out specific exploits. Where the value of adaptive auth
> would I think be more likely is a targeted attack with a known set of
> credentials where a set of actors is trying to leverage something they
> have to get elevated privileges. In which case getting a single
> openvpn running on an aws account could cost as little as a few
> dollars and circumvent many of the risk barometers based on source ip.
>
> >
> >
> > 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.
> >
>
> Sure, but I don't think KC (or any authentication system) is going to
> stop a script kiddie. The vulnerabilities they are generally going
> after are known exploits that haven't been patched and don't require
> authentication. Just watch the logs for a known wordpress site and
> you won't see any requests for authentication from trollers (unless
> its with a specific exploit). You'll see reams of trying to hit
> wp-admin with known exploits to bypass authentication all-together.
>
It's certainly not going to stop attacks going after known exploits. The
only real defense against that is limiting what's exposed and making sure
everything that is exposed always has the latest security patches. The
latter being one good reason for using a supported product rather than a
community project as you are able to get patches to older versions as well
as retrieve patches prior to the vulnerabilities being made public.
Adaptive authentication could for instance stop someone trying to use
common passwords with a list of known usernames. We have a rather naive
brute force protection in Keycloak that prevents that to some degree, but
it's far from sophisticated enough. For example it prevents many guesses to
one user, but not few guesses to many users. However, that would more
likely be the job of a intrusion detection system and firewalls to stop
those type of attacks in either case.
>
> Even looking at the articles mentioned, everything is theoretical.
> Adaptive authentication has been around for at least 8-10 years, you'd
> think if it were used to great success there would be more success
> stories rather then theories. The new part they point out is the
> addition of machine learning to the process to make more intelligent
> decisions, which makes sense. Something like Google's new captcha
> system. KC would make a great integration tool for something like
> that.
>
You're right. Simple rules like an IP range are just not going to cut it.
Much more complex and intelligent processing of data is required. If the
rules are to defensive you also end up blocking legitimate users. In which
case you need a way for the legitimate user to prove they are who they say
you are. In which case you can send a mail or even use Google's reCAPTCHA.
Even sending an email when you've detected a login from a new machine is
useful to at least detect malicious access.
One thing we should at least do is to add a device cookie which includes
the user-id that is signed with the realm key. This would allow us to
identify a device that has been used before. If we detect a new device we
can introduce options such as send an email to verify the device, display a
reCAPTCHA or even simply send an email to the user to notify about the
login.
>
>
> ps: great conversation, really enjoy these types of discussions
>
+1000
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3416
days inactive
3419
days old
8 comments
5 participants
participants (5)
-
Francis Pouatcha -
Marc Boorshtein -
Pedro Igor Silva -
Stian Thorgersen -
Thomas Darimont