Note: Gluu does not support SPNEGO.
Chatting this week at EIC with Jackson Shaw from Dell, I mentioned my frustration with Gluu customers requesting SPNEGO, “a web-specific implementation of GSSAPI which is an IETF standard” says Dan McDougall, from Kitkoff Software (see his other interesting comments at the end of this post). In practice, its generally used to enable the browser to use Windows network authentication. For example, users might say “I logged into Windows with my password, why do I need to login to the company portal again?”
One of the best ways to save money in information technology is through consolidation. Another way to say this is: “no one-offs.” SPNEGO is an old protocol connector, using a small set of Windows browsers. That is the definition of a “one-off.”
What about usability? Think about Google. How often does Google authenticate you? I could not find any way in the Google user account configuration to manage this setting. As far as I can tell, it’s never. Once I’ve logged into a browser, unless I logout, clean my cookies, or go into incognito mode, I won’t have to login to Google again–unless Google decides I’m doing something that requires re-authentication (like changing my password). And note, this is a solution for all browsers– even mobile browsers! Kudo’s to Google on creating the most usable identity management platform on the Internet.
Is a previous browser session less secure than looking for a recent Windows Kerberos authentication? In fact, access to that browser session leverages network authentication anyway. Both make a relatively loose connection to the person in front of that computer, so neither mechanism mitigates significant risk. The browser session leverages centralized security, so it is also more flexible. Policies can be configured for all sessions, including Mac and mobile.
So we have: (1) high cost; (2) same usability (probably worse); (3) worse security. But the customer is always right! When I posed this scenario to Jackson at EIC, he was sort of resigned to agree that the vendor should support the feature: “Sometimes if the customer wants to hang himself, you have to sell him the rope!”
One solution that was suggested by Yerri Lolgondar of IdentityNest was to leverage Active Directory Federation Services, the Microsoft SAML component. I like this idea a lot better, as long as you web access management platform can handle the SAML redirect. There is a blog by Oracle that provides an overview of this solution.
I understand that the customer has a checklist of features and SPNEGO is on the list. But should the vendor that sells you the rope get extra credit?
Comment from Dan McDougall:
SPNEGO is just the web-specific implementation of GSSAPI which is an IETF standard. It’s not specific to Windows.
You can use SPNEGO from Linux and Macs just fine using standard Kerberos. There’s no need to involve Windows at all.
The only time Windows-specific things get involved with SPNEGO is when you allow the use of NTLM: A highly insecure authentication method enabled by default in Windows. More importantly, unless you expressly forbid it via GPOs you’re probably using NTLM all over the place in your company’s network.
NTLM is a big problem because if you don’t setup Kerberos properly the SPNEGO negotiation *will* fall back to using NTLM without notifying the user. If you’re not using SSL then it might as well be falling back to plain text authentication! Yes, NTLM (the latest version) is *that bad*. There’s rainbow tables that exist up to 16 characters for NTLM but you can download up to 10 charcaters for free here: http://project-rainbowcrack.com/table.htm
At this point, any NTLM hash derived from a 17-characters-or-less password is considered extremely weak and easily crackable with modern GPU hardware. I myself have cracked passwords 36 characters long using a single GPU on my home theater box. You can try it yourself with free software here: https://hashcat.net/oclhashcat/
FYI: The default Windows Kerberos implementation is only marginally better than NTLM though because it too does not use a salt making password hashes only marginally harder to brute force (rc4-hmac algorithm). Even if you enable AES-256 in Windows Server 2012 or later (your domain functional level is up to that, right? =) it *still doesn’t use a random salt*! So it suffers the same problem: Only marginally better and not strong security at all.
Sigh, Windows authentication (and Active Directory) is an insecure mess across the board. To fix it you basically have to re-build or replace everything Windows or Windows related on your network with very specific (expert-level) obscure security settings. Even then you don’t get strong security due to the lack of random salts and problematic (or just plain broken) implementations of normally highly secure standards like Kerberos V5.
Subscribe to Get News and Product Updates
our RSS Feed