<div dir="ltr"><div>user(s) attached device cookies will definitive add a lot of value to KC. Simple enough to handle. </div><div><br></div><div>+1</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Best regards<br>Mit freundlichen Grüßen<br>Cordialement<br><br>Francis Pouatcha<br>Founder and Technical Lead Group Adorsys<br><br>LinkedIn: <a href="http://www.linkedin.com/pub/francis-pouatcha/8/35a/542" target="_blank">http://www.linkedin.com/pub/francis-pouatcha/8/35a/542</a><br>adorsys GmbH & Co. KG, Germany: <a href="http://www.youtube.com/watch?v=rVRkFGUNexo&authuser=0" target="_blank">http://www.youtube.com/watch?v=rVRkFGUNexo&authuser=0</a><br>Adorsys S.A., Cameroon: "African Software Competence Center"<br>Open <a href="https://github.com/adorsys" target="_blank">https://github.com/adorsys</a><br><br>Cell USA: +1 770 329 7026<br>Cell Germany: +49 172 18 16 074<br>Cell Cameroon: +237 51 74 71 99<br><br></div></div></div>
<br><div class="gmail_quote">On Tue, Aug 30, 2016 at 11:31 AM, Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 29 August 2016 at 19:06, Marc Boorshtein <span dir="ltr"><<a href="mailto:marc.boorshtein@tremolosecurity.com" target="_blank">marc.boorshtein@<wbr>tremolosecurity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>>> ><br>
>> > VPNs are certainly not the solution in all cases as more and more<br>
>> > applications are exposed directly on the Internet everyday.<br>
>><br>
>> Very true (as are all your other statements) but my point about VPNs<br>
>> wasn't that more people are using VPNs as a way to protect<br>
>> applications (probably the opposite). Its that VPNs can be easily<br>
>> used to bypass many of the features of adaptive authentication. Most<br>
>> adaptive deployments I've seen rely on geo location mappings of IP<br>
>> ranges to determine where users are logging in from. Use an OpenVPN<br>
>> into a Amazon/Google/Azure/Pick-Your-<wbr>Favorite-Proider network and out<br>
>> to the internet and that feature becomes useless.<br>
><br>
><br>
> Yep, that's an issue. There's also bot farms as well. Not many people will<br>
> issue an attack from their home address.<br>
><br>
> Still has some level of protection. For example VPNs are costly, tend to be<br>
> rate limited.<br>
<br>
</span>If you're talking about a DDoS or script kiddies just running massive<br>
sets of scripts against a target, sure but I don't think KC (or any<br>
authentication system) will be what stops that. That'll be a<br>
combination of network infrastructure and web application firewalls<br>
screening out specific exploits. Where the value of adaptive auth<br>
would I think be more likely is a targeted attack with a known set of<br>
credentials where a set of actors is trying to leverage something they<br>
have to get elevated privileges. In which case getting a single<br>
openvpn running on an aws account could cost as little as a few<br>
dollars and circumvent many of the risk barometers based on source ip.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><br>
<br>
><br>
><br>
> It does depend on what level of protection you are looking for. If it's for<br>
> a web application and you're trying to block out script kiddies and other<br>
> people looking for easy targets the rules doesn't have to be that complex.<br>
><br>
<br>
</span>Sure, but I don't think KC (or any authentication system) is going to<br>
stop a script kiddie. The vulnerabilities they are generally going<br>
after are known exploits that haven't been patched and don't require<br>
authentication. Just watch the logs for a known wordpress site and<br>
you won't see any requests for authentication from trollers (unless<br>
its with a specific exploit). You'll see reams of trying to hit<br>
wp-admin with known exploits to bypass authentication all-together.<br></blockquote><div><br></div></div></div><div>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.</div><div><br></div><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Even looking at the articles mentioned, everything is theoretical.<br>
Adaptive authentication has been around for at least 8-10 years, you'd<br>
think if it were used to great success there would be more success<br>
stories rather then theories. The new part they point out is the<br>
addition of machine learning to the process to make more intelligent<br>
decisions, which makes sense. Something like Google's new captcha<br>
system. KC would make a great integration tool for something like<br>
that.<br></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
ps: great conversation, really enjoy these types of discussions<br></blockquote><div><br></div></span><div>+1000</div><div> </div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>