sso vs … not

  • SpinRite v6.1 Release #3
    Guest:
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

slartibartphast

New member
Sep 30, 2020
3
0
my parent corp is big on okta and sso including vpn.

in my division we’ve got gmail, windows ad sone old ldap linux and aws stuff.

me, i’m paranoid about having an account for email get compromised and boom you got vpn ssh etc. it seems to me sso puts never use the same password idea out the window.

plus with these web sso ir seems the danger of phishing is way higher even with 2fa.

opinions?
 
I presume your thinking is that having multiple passwords is better? That doesn't make a lot of sense to me. It's like the difference between having one front versus many fronts in a war. You're usually better off to focus your attention protecting one thing really well, rather than trying, and usually failing, to have good protection for many things. If you're the kind of person to get phished or otherwise likely to lose your password, having more ways to cause you to do it is just more ways to fail.
 
It’s a double-edged sword.

Some of the things we can do with SSO is ensure that the all the services require multiple factors for authentication, even if the service itself has absolutely no support for it. Another benefit is that if the account gets compromised or the individual leaves, we can quickly disable the account — even automatically. Also, it is easier to have one strong password, than multiple small ones.

Yes, they are cons, like lateral movement between SSO secured services. All of it will be part of the company’s risk assessment.

In summary, SSO is more closer to being a single service, with the third-party keeping an identifier and no password. They receive a signed assertion signed with the service-specific identity provider issued certificate at sign-on time instead (SAML), or cryptographic token (Kerberos).
 
Last edited:
I suppose you could imagine SSO for an enterprise is like an individual using a password vault, like LastPass. Either of them enables adding MFA to accounts that don't support it, and requires a single, strong password for the user to protect what amounts to SSO tokens or generated complex passwords for LastPass protected sites,

As an individual, I choose NOT to use SSO solutions that are offered me by various sites ("sign in with Google, FB, or Twitter, etc), as I cannot control how secure those solutions are. An enterprise SSO solution on the other hand, supposedly has a lot of attention paid to the plumbing.

On the other hand, I'm a real believer in using LastPass, as I find it indispensable for managing logins for 200+ different web sites. I protect my LastPass account with Yubikeys. On a personal note, I use LastPass Families, especially for the 'dead man' feature, where my spouse can gain access to my logins, if she requests it, and I don't block the request within so many days. If you've ever had to deal with losing a loved one, and not being able to access any of their online accounts without a LOT of mumbo-jumbo, you will appreciate this feature.
 
I think "Strong Authentication" is a must. We use smartcards and certificates to achieve this goal - which is very important for us when you consider both internal and external service authentication. It's especially important, in my opinion, when using Cloud-based services where we demand our own tenant, HSM-based encryption management and certificate-based authentication to profiles and roles that we deliver as a basis for authorisation to the service.

The biggest user-facing advantage is that we subsequentally block access to such Cloud-based services for our people from non-authorised, non-enrolled devices (such as personal PCs). SAML and Kerberos are king and bring a seamless and integrated authentication

In an enterprise like us, LastPass and the like would not work; we have designed Temporary Priveleged Access mechanisms for most platforms that are driven on a request, time-limited basis. It also then leverages the same certificate, negating the need for access to a separate credential but, at the same time, having that identity working in their daily environment (endpoint) as a non-admin.
 
I suppose having a per device cert would really lock down the scope.
I’m also leery of roles keeping people out of certain systems. For example we have some pci stuff in aws with totally different credentials. That way some admin can’t badly assign a role and give access.
 
To be clear, my enterprise uses LDAP and WiFi certs, etc. to lock down access to authorized sites and authorized devices. I'm not in our IT group, so I can't speak much to what goes on there, just what I experience as a user.

LastPass is for my personal use. The enterprise tolerates it, for that usage, because they understand that users will need to get access to personal sites (banking, webmail, etc) and if they block things like LastPass, it will only encourage poor security practice on their machines.
 
To be clear, my enterprise uses LDAP and WiFi certs, etc. to lock down access to authorized sites and authorized devices. I'm not in our IT group, so I can't speak much to what goes on there, just what I experience as a user.

LastPass is for my personal use. The enterprise tolerates it, for that usage, because they understand that users will need to get access to personal sites (banking, webmail, etc) and if they block things like LastPass, it will only encourage poor security practice on their machines.
We use corporate lastpass! So maybe your it guys may want to look into it. it’s great for sharing tons of passwords for machines that we don’t use ldap on like routers switches and hosts.

plus you can link your personal account and use both.
 
SSO + 2FA
Make sure that SSO is properly configured so that your users aren't giving out the password to a third-party. This means that third-party websites will be temporarily redirecting back to your domain.
Make it so one can only configure 2FA from the domain network. (not VPN)
This of course means that users who are 100% remote, will have to call in, to get 2FA configured and changed.