Your SlideShare is downloading. ×
Online Authentication
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Online Authentication


Published on

In this article we explain how to increase your security posture against online spoofing. …

In this article we explain how to increase your security posture against online spoofing.

Published in: Internet, Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Marc-Andre Heroux, CGEIT, CISA, CRMA, CRMP, ABCP, CISSP, NSA-IAM, NSA-IEM LinkedIn: Twitter: @herouxma | IRC: herouxma on There are many types of spoofing attacks online In this article we explain how to increase your security posture against online spoofing Date: May 16th, 2014 Draft Version 1 Online Authentication Federated information technology systems
  • 2. Prerequisites • In this presentation, the clients and servers were not compromised; • for critical Web applications, all communications must be in a tunnel (ex.: VPN); • for critical activities accessing sensitive information, using a RSA Secure ID is strongly suggested; • all exchanges must be done with the corrected SSL if not in a tunnel. 2
  • 3. Validating against a server, a nonce at layer 5 can prevent: CSRF and spoofing (ex.: SAML). Web servers cluster Identity Provider (IdP) If authentication successful (receive secret) Receive requests based on a secret Verify and validate Secret (ex.: SAML ID) Use Web Application Directory (ex.: secure LDAP) 1 2 3 4 Deliver authorized content6 Server validation (SAML) Threat Agent Sends email with malicious codes and conduct various external attacks from layer 3 to 7. 3 JavaScript/Ajax Authentication Hijacking 5
  • 4. ● Comparing server generated nonce vs nonce submitted in hidden HTML form field value is also considered a good practice; ● then we have Web authentication as follow: something you receive from web server (nonce) and something you send to web server as a client (nonce). Server validation (CSRF) Threat Web Server SAML TTL Web Server Read cookie SAML ID Cookie in browser Web Brower Nonce hidden field Malicious code sent in custom form and post to Web server 1. The attacker doesn’t know the nonce; 2. The attacker can’t guess the nonce; 3. The attacker cannot send the nonce in a hidden field; 4. Server or WAF reject the post.Confidentiality, integrity and accessibility of the SAML ID 1. The IdP must always be available so well protected (hardened, monitored, etc.); 2. The ID can be retrieve in header by a Man-in-the-middle attack (VPN and correct SSL can protect); 3. The ID must be long enough and not be guessable; 4. The ID must be compared between Web server and IdP before authorizing access. Likelihood of the attack If the SAML ID is compromised: 1. The attacker will gain access to your Web application for the time-to-live of the SAML ID; 2. If the IdP or the LDAP server are compromised, the overall solution is compromised; 3. To prevent a complete take over of your infrastructure by an attacker, never use a critical account without a RSA Secure ID. Compare nonce post vs set by server Success 4 Cookie
  • 5. Subject and object: always make sure to identify and authenticate your subject or your object and provide proper authorization to reduce potential false negative results and security incidents; JavaScript/AJAX: can be easily injected and you cannot rely on it without server validation (ex: IdP); The cookie: name and values must not be guessable or stealable; The maximum cookie size: about 4K. Few basics principles 5
  • 6. Among others, when using cookies its important to follow these principles: • Limit the amount of sensitive information stored in the cookie; • Limit the subdomains and paths to prevent interception by another application; • Enforce SSL so the cookie isn’t sent in cleartext; • Use values hard to guess (name, IDs, etc.) and set expiration value (the more critical, the shorter); • Make the cookie HttpOnly so its not accessible to javascript. 6 Who stole my cookies?
  • 7. If form hidden nonce value different than server nonce set for current client session, it's a threat; if SAML ID in header is different than server xml http request result of ID stored @identity server provider, a threat tried to forged the SAML ID; else, the context can be considered acceptable. Exemple of a SAML ID: <saml:Assertion ID="_b07b205c-7c29-gr16-4300-5f3e6f7923vc " IssueInstant="2014-18-05T18:35:10.728Z" Version="2.0"> <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"> </saml:Issuer> Pseudocode 7
  • 8. Also and not new: most common IP spoofing can usually be dropped and logged by a basic packet layer 3 firewall. # netfilter/iptablesRule 0 (eth0) # # anti spoofing rule # $IPTABLES -N In_RULE_0 $IPTABLES -A INPUT -i eth0 -s -j In_RULE0 $IPTABLES -A INPUT -i eth0 -s -j In_RULE_0 $IPTABLES -A INPUT -i eth0 -s -j In_RULE_0 $IPTABLES -A FORWARD -i eth0 -s -j In_RULE_0 $IPTABLES -A FORWARD -i eth0 -s -j In_RULE_0 $IPTABLES -A FORWARD -i eth0 -s -j In_RULE_0 $IPTABLES -A In_RULE_0 -j LOG --log-level info --log-prefix "RULE 0 -- DENY " $IPTABLES -A In_RULE_0 -j DROP ! Cisco Rule 0 (Ethernet1/0) ! anti-spoofing rule ! access-list outside_acl_in remark 0 (Ethernet1/0) access-list outside_acl_in remark anti-spoofing rule access-list outside_acl_in deny ip host any access-list outside_acl_in deny ip host any access-list outside_acl_in deny ip host any access-list outside_acl_in deny ip any access-group outside_acl_in in interface outside Here is an example of iptables and cisco rules for internal network (match all addresses of the firewall (, and network behind it ( State-full Packet firewall 8
  • 9. Integrity and confidentiality are very important in the authentication process and avoid the use of cookies is suggested, especially for critical applications; In order to support the authentication, authentication systems must be available at all time (ex: IdP server); The likelihood of an attack in this scenario is considered the duration of the session SAML ID key, little bit similar to the likelihood of a RSA secure ID token; Restrict POST from legitimate and acceptable source only and use nonce; While using an RSA Secure ID device for critical activities, we increase the security posture to a very interesting level; Many security appliances are using the same CA private key across all devices. This is particularly dangerous, since the universal CA private key can be extracted from any single device by an attacker. With the private key, the attacker can be seen as trustable by all devices using the public key to secure transport as well as payload. Conclusion 9
  • 10. Carnegie Mellon University, Analyzing Forged SSL Certificates in the Wild, Lin-Shung Huang, Alex Rice, Erling Ellingsen, Collin Jackson Oracle, Developing Security Providers for WebLogic Server, Identity Assertion Providers, Robert Hafner, How to Create Totally Secure Cookies, FirewallBuilder, Anti-spoofing rule, IBM Research - India, Security Analysis of Web-based Identity Federation, Apurva Kumar Cisco, SAML SSO Deployment Guide for Cisco Unified Communications, Applications, Release 10.0(1), First Published: December 06, 2013, Last Modified: May 08, 2014 OASIS, Assertions and Protocols for the OASIS, Security Assertion Markup Language, (SAML) V2.0, OASIS Standard, 15 March 2005 I want to thanks the following sources and authors: 10 References