That you said you were interested in solving:
As was stated in this article:
“RSA CONFERENCE 2012 — San Francisco, Calif. – The way browsers perform SSL certificate-revocation checking is so fundamentally flawed, that some browser vendors have turned it off altogether”
What was reviewed at the conference was the established system that determines how a certificate issued to a user is deemed invalid. The current mechanisms are:
As we stated back in 2010 in this whitepaper: SecureAuth Solves X.509v3 Authentication and Certificate Revocation:
-
PKI is Difficult to Deploy – SecureAuth is Not
-
PKI is Difficult to Maintain – SecureAuth is Not
-
PKI is Difficult to Scale – SecureAuth is Not
-
PKI is Difficult for Application Integration – SecureAuth is NOT
-
PKI is Difficult for End-Users to Obtain Credentials – SecureAuth is NOT
The white paper spans 20 pages of detail, so I will summarize the key points below, for the quick version.
Certificate revocation is how to render the identity of an X.509 certificate null and void. In other words, “Fine you have a certificate, but I no longer trust it for the sake of this transaction.”
- “PKI is the only technology in the world that requires:
- A list of all valid credentials
- A list of all invalid credentials”
It is this 2nd list, the “anti-database,” that has made PKI all but impossible to deploy and maintain.
It’s easy to sit here, in 2012, and say, PKI w/ it’s CRLs and OCSPs is stupid. Well, it is stupid. Actually it is REALLY stupid in the context of 2012.
Seriously… try this. Go to your e-mail admin and tell him..
“I want you to check EVERY invalid user before you allow him access to his e-mail. E.G. check everyone
you ever suspended/deleted from your Active Directory and/or Google Directory – before giving him
access to e-mail”.
The admin would just say, uuhhhh, you are stupid. But this is exactly what “traditional PKI” does. (See Image #1)
Image #1: CRL/OCSP certificate revocation has always been hard. Wwith SaaS services, as Google states, it has become practically impossanible.
Maintaining “anti-database” is what you are trying to do with traditional “certificate revocation”. But why is this system so backward?
The dates of these “anti-database” technologies is illuminating:
o CRL – Certificate Revocation List (RFC 1422) 1993
o OCSCP – Online Certificate Status Protocol (RFC 2560) 1999
So Google is right to say that CRLs and OCSPs have no place in 2012. GOOGLE WAS NOT EVEN INVENTED when the RFC for CRLs was published!
Having worked for RSA back in the 1990′s – let me explain their (dated) reasoning:
Directories (let alone the Google cloud-based IdP) were NOT widespread. Active Directory was not even made available by Microsoft till 2000. Thus what the certificate people said is:
- I will issue certificate to users
- When I want to revoke a cert – I will add the specific serial number to a list of revoked certs
- And every time I want to validate the cert
- I will check against these list
OK – but anyone who has done ANY work in directories and, well, web/SaaS programming, would just redesign this workflow to have the revocation occure out of the central datastore. (AD, LDAP, Google store, etc.)
In fact, a real improvement would be…
- Allow the enterprise to choose their primary datastore
- Any datastore:
- AD, LDAP, ODBC, SQL
- Google, etc
- Utilize existing datastore attributes
- No LDIF’s, No schema changes
- Enact the revocation via a simple “generic” process
- E.G. just set a “Revocation Time” to current date.
This is what SecureAuth does.
Brief Detail:
The whole theory behind this is that every cert has (2) bits of time-stamped info:
- Issue Date
- Expiration Date
SecureAuth creating a system to:
- Issue the certificates
- And Validate the certificate
Please pay attention to this 2nd part, Google. (And anyone else interested in, once and for all, resolving the “revocation” problem.)
Because SecureAuth validates the certificate, SecureAuth can then check a datastore (any datastore – on premise or cloud based) – for the revocation time. (See image #2). Thus SecureAuth does NOT have to rely on (outdated CRLs and OCSPs!)
Image #2- Un-authenticated users (A) get redirected from SaaS and On-premise resources to SecureAuth. SecureAuth (B) conducts the authentication (and Cert Validation) and then asserts a “positive assertion” back to on-premise and SaaS (Google) resources (C). No CRLs or OCSPs are needed.
Of course, as stated, you can download this whitepaper , or you can just contact us. we will tell you more! (And of course, we got patents filed on this dating back to 2007!)
All the best!
–
Garret Grajek is CTO and a co-founder of SecureAuth. SecureAuth is a single appliance solution that delivers configurable 2-Factor and SSO authentication for Web, VPN and SaaS based solutions.
We’ve all seen the news reports, so & so’s email got hacked and all of their laundry is hanging out for all to see. Twitter, Puckett & Faraj and many others have been burned badly by not securing their cloud based email.
You don’t want to be next.
Moving to Google Apps makes a lot of sense, it can save you a ton of money, rack space & payroll but with all of that functionality comes greater risks. So how can you go from forcing your users to remember different passwords to becoming the toast of the water cooler?
Install SecureAuth.
In about 2 hours we can bring you from
Forcing your users to go though this? It's not safe...
To this!
Yes, your internal users aren't logging in to this! They won't believe it!
This process literally takes about 2 hours! The best part is, you can support different work flows depending on the users location.
Internal users typically get Single Sign On to SaaS applications like Google Apps.
External users we typically automatically direct them to a use case that your comfortable with (yes, we’ll show you all the options when we help you set up everything).
So, there you have it, you’ll be partnered with the number one solution for federated access to SaaS applications in the world. Your users might actually buy you a cup of coffee and best of all you’ll have secured an important business tool with the best security solution being sold today.
Shoot us an email at sales@gosecureauth.com and we’ll show this isn’t impossible, you don’t need multiple products and best of all you don’t need to break your budget to get this functionality in house.
Google’s created the G.S.A, no not the GSA we’ve all heard of but the Google Search Appliance. What does this mean to your organization? Basically it means that you can put this appliance in your network and it’ll crawl all the nooks & crannies of your network and allow you to instantly search for things you’d like to find out about?
I’m not talking about the Z:\ drive on your single file share server, I’m talking about huge organizations that create thousands & millions of documents. That’s where the Gsa shines.
Another thing that’s great about this appliance is that it also supports something called SAML. This basically means that you can off load the authentication to another appliance called SecureAuth. Why should you choose SecureAuth to perform the authentication? Because we can allow users to authenticate using whatever you’d like.
One of the most popular integrations SecureAuth does is using CAC or PIV cards as a factor of authentication added onto something else like a username & password in Active Directory. Basically SecureAuth can validate the identity on this card, extract the common username, authorize it in Active Directory or whatever directory you use and only after we’ve validated this and logged it we can turn it into access to the Google Search Appliance!
Yes, SecureAuth can do this, we can set this up in 1 (yes one) day for you.
Click on the image to open up in a large format.
So there you have it, if you’re already using these appliances and want to turn up authentication on specific searches just shoot us a note at sales@gosecureauth.com
From the soon to be released white paper -
Today’s IT security professionals spend more and more time dealing with one cumbersome task: managing user identities. Even for organizations that have adopted advanced authentication mechanisms, identity management is still a time-consuming cost center. Password resets alone take up an undo amount of IT resources.
As more mission-critical applications migrate beyond the firewall and as SaaS, Web Services and cloud-based applications continue to rise; organizations are learning the hard way that their access and enforcement mechanisms aren’t ready for the Web 2.0 world.
To combat application sprawl and minimize the impact on end users, most organizations are moving towards single sign-on (SSO) solutions. However, legacy SSO solutions can’t stitch together the many on-premise applications with those beyond the firewall. Access-control platforms, two-factor authentication tools and identity federation all tackle parts of the problem, but unified solutions are elusive.
To prevent competing solutions from creating too much chaos, standards bodies have stepped in to propose underlying SSO and identity federation standards, such as SAML (Security Assertion Markup Language) and OpenID.
SAML caught on quickly with cloud-based providers, such as Google, Salesforce.com and WebEx, and once traditional companies such as IBM and Microsoft threw their support behind SAML, it became the go-to SSO protocol for SaaS applications.
What SAML Does
SAML is a framework that enables the exchange of security and identity information. It is not a solution that grants access or enforces identities. The main difference between SAML and other identity mechanisms is that SAML relies on “assertions” about identities. It is assumed that an Identity Provider (IdP) is making an assertion and that the IdP is responsible for maintaining user identities, authenticating users and determining privileges.
SAML enables enterprises to abstract authentication from applications. Rather than having to manage multiple credentials for a variety of apps, SAML allows organizations to extend identities from in-house resources to external service providers.
This one trait alone boosts security. When users have multiple credentials for various apps, they inevitably do one of two things (both of which erode security): they either repeat credentials from app to app, or they write them down.
If credentials are repeated, each resource that person uses is only as secure as the least secure one. If a hacker breaches one, he’s effectively breached them all. Writing down credentials is just as bad. Hackers have long known that if they find or steal someone’s laptop, they merely have to run a search for a file named “passwords” to dredge up a list of credentials.
SAML allows enterprises to:
- Standardize authentication assertions
- Retain identities in single repository
- Abstract authentication so that it is not tied to a specific application
- Extend identities from internal to external resources
- Log authentication locally
How an Identity Enforcement Platform Works
- Identity Enforcement Platform pulls the identity from the enterprise data store (AD, LDAP, SQL, etc)
- It then conducts either:
- Secure Desktop SSO (Intranet)
- Secure 2-Factor Authentication (Extranet)
- Identity Enforcement Platform passes the identity on to:
- Hosted Web Apps (Microsoft, IBM, J2EE)
- VPNs
- SaaS applications (salesforce.com, Google Apps, Postini, etc.)
- And provides added security in the form of:
- SSO between resources
- Policy-based group authorization
- Unified SSO across apps both on-premise and in the cloud
See – http://www.gosecureauth.com/solutions/cloud/saml.aspx
SecureAuth – Assert Your Identity - Want to know more? … give us a call – 949-777-6959
Greetings:
The word’s out – SecureAuth has done authentication the right way. (Amylin, Carnegie Mellon, Carnival Cruise Lines, Carolinas Health Care, Chevron, City of Beverly Hills, Diebold Inc. Dish Networks – just follow the link.)
And we are not apologizing. (See image #2)
Image #1: Available SecureAuth engineers – who represent the greater SecureAuth community – who are proud of building a better authentication/identity product.
When Craig Lund and I started this company in the winter of 2005 – we set forth to correct some of the mistakes in the authentication business. I personally have been involved in hundreds of authentication and identity projects as an engineer at Security Dynamics, RSA, Netegrity, IBM and Cisco.
When we designed SecureAuth, we weren’t going to repeat the mistakes of:
Image #2: SecureAuth solves the failed designs of previous Authentication Systems.
Authentication Flexibility:
The problem with previous solution – is they were either:
- Single Functionality Authentication System (RSA SecurID)
- Cobbled Authenticaiton Systems (SafeNet)
There has never been a single authentication authentication platform built in with a:
- WebServices to high-availability SMS, Telephony, PKI systems
- Full support for both out-of-band and other auth methods (X.509, CAC/PIV, Yubikey)
- Utilization of local datastore information (KBA/KBQ, Help Desk)
Authentication Integration:
Well, lets be frank – this is where SecureAuth wins. Hands down. Why? Because the other products are just kludgy pure-play authentication technology where no programmer ever stood up in the meeting and say, “Excuse me – this crap is undeployable”. (Uhm, I know that – because I was that engineer @ RSA an IBM.)
SecureAuth is the only V.A.S. (Variable Authentication Server) with a built-in:
- Application Server
- Web Server
- Web Service Authentication Interface
That’s why SecureAuth always wins in P.O.C.s SecureAuth can actually execute on the functionality that, well, the architecture team is trying to execute on. And fact of the matter is – we probably already have and its been incorporate into our current release.
Try saying that with your token-based API system.
SAML / SaaS Integration
People – SAML is not a mystery. It’s just an XML file, that needs to be cryptographically signed by a X.509 private key. Oh – and you need send the right identity to the relying party – that may (but pbly not) match the ID that the user authenticated with.
Oh – and you should probably give some flexibility on how the user is authenticated – and provide some SSO for other SaaS/Web apps and your Active Directory domain.
Oh – and you should hook up the authentication to your SIEM system.
Lastly – gives the user some functional portal – that they could use both on the computer – and their mobile phone and tablet.
Got it? Good.
No one else does – except SecureAuth
.
PKI
If you are still defending PKI in all is achronistic dysfunctionality – then well you still can’t figure out why Colleen dropped you in high school for the guy with the better car and party circle. (I mean – you did have your Gremlin polished and you had planned to meet “Skeeter” and “Catch” at the bowling alley.)
Bottom line:
Any technology that says you must track all the IDs that are invalid – is well stupid. Seriously, people – that is just stupid.
Grow up – sell the Gremlin and read this.
Mobile
This last one really baffles me. How the “Traditional” IT industry has responded to the BRILLIANT, GROUNDBREAKING beauty of the mobile explosion: They say, “I know – we’ll take all these wonderful mobile devices and turn them into 1960-era CRTs with these undeployable MDM solutions.”
Seriously people – adjust to freedom.
The wall fell in 1989. (Look it up – it’s documented – there this whole Reagan/Gorbachev thing – its a good read – or late night History channel watching).
It’s a BYOD world. If your company has a policy that you must own everything on the mobile device – wake up – they laid off 30% of the staff in the last recession – the people accessing the resource are all contractors, suppliers, temporary employees – etc.
You don’t have a right to tell people what they run on their devices.
You don’t. The future is dumb devices and cloud storage – so seriously – give up the “control freak stuff”.
The wall fall. So will the MDM effort. Adjust.
All the best.
–
Garret Grajek is CTO and a co-founder of SecureAuth. SecureAuth is a single appliance solution that delivers configurable 2-Factor and SSO authentication for Web, VPN and SaaS based solutions.
Comments
Comments Off |
Categories
Blog
|
Author
Garret |
|
One of the key SecureAuth message in 2012 is how enterprises need to adjust to a BYOD. And that does not mean just purchases a mechanism (MDM) or other to manage personal and corporate mobile devices.
Remember: The Devices may be new each quarter – but the regulations (like PCI DSS, NCUA, FFIEC, HIPAA/HITECH) are not.
Which is why SecureAuth is so line with the 451 Group’s report on mobility and app control:
The report has some very key observations, including:
The fundamental issue that IT departments and security teams face with BYOD (bring your own device) is that they cannot stand in the way of mobile adoption – both because of user preferences, and because there are obvious productivity gains for the organizations. However, mobile adoption generates two major issues: there is no direct control over the device by IT or security, and traditional enforcement of ondevice data use andapplications can’t be readily extended to employee devices accessing corporate resources.
An astute problem statement – of course – but is also relevant is the the accurate assessment of SecureAuth in the 2012 BYOD market.
Which make SecureAuth had already launched a set of capabilities for supporting SSO from Apple iOS and Google Android mobile devices (building on existing mobile OS support), as well as automated enrollment and management of X.509 deviceside certificates. Now the company has looked to extendthose capabilities to bridge iOS device side certificates with Microsoft infrastructure through its ‘funnel.’…
The use case is significant not just because it illustrates the strengths of SecureAuth’s platform. It also allows the company to position itself as asubstitute for mobile device management for smartphones and mobile tablets, as well as establish a strategic footprint as enterprises migrate from Exchange to GoogleApps.
This really is the world in 2012.
It’s not just the issuing of mobile devices that enterprises need to worry about – it’s the whole new conundrum of how to provide access to corporate resources – that, well – aren’t at the corporation. E.G. the apps themselves may be in the cloud.
So now we have (2) intangibles in 2012 – that are no longer solved by the “crunchy shell” network topographies of the pre-cloud age, we have:
(A) – Mobile Devices – not part of a corporate domain
(B) – Cloud Apps – not part of a corporate domain
(Please see image #1 below.)
Image #1: SecureAuth helps enterprises with the (2) major technical advances in 2012 – (A) Mobile Devices and (B) Cloud Apps.
Learn more about SecureAuth BYOD capabilities from additional SecureAuth reading and/or our latest BYOD Webinar. Of course, you can just contact us – and we will tell you more!
–
Garret Grajek is CTO and a co-founder of SecureAuth. SecureAuth is a single appliance solution that delivers configurable 2-Factor and SSO authentication for Web, VPN and SaaS based solutions.
No Service Provider or SaaS provider knows the power of federation better than Google which is why they’ve installed the SecureAuth Identity Enforcement Platform into their SE Lab. We work with many different SaaS Providers but Google has changed the game forever. While Microsoft deals with long downtimes on it’s platform our Google customers enjoy a service that’s always up and accessible from anywhere in the world. On top of that they’ve created API’s that allow SecureAuth to provision accounts and to even allow SecureAuth to provision corporate Google Apps accounts on iOS and Android devices.
Google SE’s can now demonstrate SecureAuth’s totally unique features such as 1 login URL that treats internal and external users differently and to even allow Google Apps customers to decide just what they want to use to authenticate users with respect to CAC & PIV cards, multifactor authentication or SSO.
SecureAuth Portal in a box
Their appliance has been configured to allow administrators to authenticate using 2-Factor authentication and to then provision users in Active Directory right through SecureAuth. Users can then log into the Portal with their account, validate their identity and get access to Google Apps. If the user doesn’t have a mailbox yet SecureAuth will go ahead and provision that for them.
User Portal
Special thanks to Milton Keath from SecureAuth and the Patrick Nolan from Google for putting together a great partnership portal!
If HTML5 doesn’t work you’re probably using IE. Sounds like a biased joke doesn’t it? Well in some aspects it’s 100% correct.
Adrian Bateman, a program manager at Microsoft’s ID group stated once that they flat out don’t want to conform to the HTML5 <keygen> specification. As a matter of fact, they want it removed (REFERENCE)
Basically it boils down to this, they think that if you use your browser to enroll for a certificate through HTML5 it’s somehow not secure. Better to just log into a domain and get a cert pushed down to your PC behind the scenes? We’ve been though this argument many times, if you get a certificate pushed down to your PC from your CA by just logging into the domain it’s really good for nothing more than device identification. This shouldn’t be used for validation of a user, ever.
Why does the fact that Microsoft doesn’t conform to the HTML5 spec bother us? Well it doesn’t really because we’re typically using Chrome, or Firefox, or sending letters via the USPS even but what is ironic is this, you can get a certificate using Chrome and then use that same certificate in IE as user authentication. Are you seeing the humor here?
So, the main argument from Adrian is that it’s too insecure to allow users to enroll for a certificate in IE, sounds like the reason the domain admin didn’t want to allow iPads on the network right? Well SecureAuth is now able to walk users through an enrollment process that not only ensures a users identity via the information they have in Active Directory but we can now create certificates in your browsers store via HTML5, that is as long as you’re using a intelligent browser like Chrome, Firefox or Safari. If you still want to use IE you’ll still have to utilize the ActiveX controls, until Microsoft brings IE into 2012 and beyond.
SecureAuth is please to release the first enterprise grade variable authentication service that’s deployable with an iApp.
What’s a Variable Authentication Service? It’s SSO & or 2-Factor to your SaaS applications, VPN or whatever you’d like! It’s easy to use & deploy 2-Factor authentication for users trying to access your Sharepoint, Citrix or webtop deployment. It’s also something that can consume authentication from inside of the F5 APM to preform SSO to cloud applications. Let’s just say, it’s the yin to the F5 yang.
What’s so great about an iApp? The iApp is a concept created by F5 that allows you to quickly deploy something. Why spend hard earned cash that you might or might not have trying to recreate the wheel? F5 has iApps for just about anything you’d care to deploy, Citrix, Sharepoint, Exchange, Oracle, SAP, Peoplesoft & many more. (REFERENCE) Now you can use an iApp that’s been co-developed with some of the brightest minds at F5 to quickly secure your applications with 2-Factor authentication. Basically, these iApps are there to make you look like a superstar. Look for a video soon demonstrating how to install and use the iApp!
F5 iApp on DevCentral
SecureAuth hosted iApp
A year ago, March 18th, 2011 – RSA announced that a hack occured on their facilities that compromised the security of the RSA SecurID tokens. RSA’s executive chairman, Art Coviello released an open letter which confirmed the breach of their security systems and revealed that the breach had been an attack on the SecurID authentication system, deployed at over 25,000 customers.
A year later: Where Are We Now?
Seriously. Many of the articles after the hack revealed what security types had already been saying for years (Bruce Schneier in lead) – the basic underlying premise of sending OTP codes for 2-Factor authentication is susceptible to simple Internet attacks, including Man-in-the-Middle attacks.
(After the attack – I even demonstrated to an assembled team of one of the largest security firms in America -FishNet Security- how easy it is to set up a Man-In-The-Middle (MITM) attack on RSA SecurID tokens. FishNet was so impressed by what was shown, they began to not only sell SecureAuth, but also use SecureAuth as a more secure and easier to use way of providing 2-factor authentication for their own remote access).
SecurID Does NOT Protect Against Modern Internet Attacks
SecureID, and other OTP token methods, do NOT protect against modern hacker mechanisms such as man-in-the-middle attacks. Modern hackers know that methods such as hard tokens (and OTP mechanisms like phone delivery systems) are just sending identity information without validating the authenticity of the relying party into which users are trying to access (EG. – unless a person can guarantee that they are sending the OTP, the password or even a RETINA scan to the correct server that’s supposed to be receiving this information, that user might as well be handing the hacker his username/password, because simply using SecurID or any OTP-type of security will not protect him from a hacker taking his credentials from his web session).
What has been known to elevate internet security is a system that is capable of:
- Authenticating the veracity of the user
- Authenticating the veracity of the authentication party
Image #2: RSA SecurID , and all the hard and soft token solutions, never addressed the issue of bilateral authentication – or who am I passing my credentials to?
So What Does Solve the Client-Internet-Server Security Issue?
The industry has known how to solve the client-server authentication issue since the
80′s with PKI ( e.g. the exchanging of key information for the purpose of bilateral (client/server) authentication). With bilateral authentication, a user is assured of the veracity of the authentication party with a cryptographically non-refutable request/response sequence between the client and the server. The actual exchange is handled under the precept of cryptographic hexadecimal numbers stored as public and private keys.
And…
The systems were never implemented in mass markets because they were too difficult to scale. I know this for a fact because Iworked for RSA in the 90′s. When we were explained how PKI worked and why it was imperative for secure Internet commerce, the “too difficult” response was always cited as the reason why PKI was not accepted in the mass market.
It was a simple business decision. When things are too costly, Industry looks for alternative ways that are not as good. In response, the industry bought technology like SecurID when companies wanted to “be secure” – or at least show they were trying to be secure. (Like the public facing financial internet site that uses RSA SecureID – that we showed can be hacked by a simple MITM proxy.)
And what has happened?
Well, now the world is nothing but client-server authentication across the internet, most of which is done over public channels (e.g. a browser to a public facing web server). The move to the cloud, intelligent as it may be for cost-savings and efficiency, has greatly advanced this type of communication.
…And the hackers – are having a field day. (See image #3)
Image #3: Hackers have taken advantage of the fact that most authentication (UserID/Password, SecurID and other tokens mechanisms) are unilateral – and thus susceptible to Man-in-the-middle (MITM) attacks.
So What Can Be Done?
The problem remains the same, regardless of what new pieces we add to the puzzle: (In image #2, Mobile devices on the left side and “Cloud resources” on the right hand side). We need a mechanism to ensure the veracity of both:
-
The Client (Desktop, Mobile, Tablet)
-
The Server (Enterprise, Cloud, SaaS, PaaS)
And now more than ever, a browser-based solution.
The SecureAuth solution solves this authentication problem by:
- Automatically issuing a cryptographic credential to the user
- Authenticating by the SecureAuth Solution
- On Premise or
- In the Cloud
- Passing the identity
- To an on-premise resource (web, VPN)
- Cloud Resource (Google, Salesforce, Workday, SuccessFactors, Amazon, etc)
SecureAuth: Bi-Lateral Authentication that Solves MITM Attacks
Why this is more relevant than ever in 2012?
The world is moving to a pure browser-server world, with the browser being the client of choice regardless of the device being used for access. (Google is adding over 5,000 customers A DAY in 2012 on its browser-pure Google Apps cloud system.)
The world is in need of a new authentication system. A system that can deliver strong authentication that meets today’s regulations (PCI DSS, NCUA, FFIEC, HIPAA/HITECH) despite the fact that users are not necessarily part of any domain, can request access from any location, can use any device, and will access not just internal enterprise resources, but also cloud-based resources.
The world needs SecureAuth.
Contact us – and we will tell you more!
