6 ms·
In a world where you don’t have long held credentials - how do you get the short term credentials?
by glenjamin 8y ago
In a world where you don’t have long held credentials - how do you get the short term credentials?
- guelo 8y agoYou could have a key rotation process where you use the old key to install the new key and delete the old key. But it seems sketchy because if you don't rotate in time the old key expires and you're locked out. I think in practice you'll always end up with a super-duper secret, rarely used, long term key. Or have some other backdoor like root password, LDAP/Kerberos, ADFS, etc.
- cbhl 8y agoIf I understand correctly: with long-held credentials. Basically, you use long-held credentials to generate short-term credentials, and then use the short-term credentials themselves to access whatever server or service you need.
- deleted 8y ago[deleted]
- xyzzy123 8y agoWe do this: Master user records in an identity/SSO system. We use ADFS. Use a protocol which provides a portable “signed”, temporary credential. We use SAML but OIDC also works. Have a command-line client which auths to the SSO and then relays an identity proof to a trusted component (lambda, cloud function, dedicated instance, whatever your policy says is ok). The identity proof is just a saml assertion or oidc token. Have trusted component validate the identity proof from SSO and generate time limited credentials (we issue ssh, kube and iam). Our client then auto-xfers those creds up to jumpbox but you could drop them on workstation instead if your policy allows.
- tptacek 8y agoThis is roughly what I'm talking about when I bring up SSH CA short-lived credential workflows.
- wvh 8y agoI currently work in academic environments and I don't have much faith in the SSO systems. I thought about this, but often the SSO credentials are also the email password – the one password that gets entered and stored just about everywhere for the average user. I'm not willing to bet the security on a user's main login/email password, which seems to be a common setup. With that password or even just access to a user's main mailbox, a smart attacker might get through multiple layers of security by simply convincing services or staff to reset credentials. Though it might work with a second, more limited (not-so-)SSO system for specific users and environments.
- lvh 8y agoYou're right that shitty systems train users to be phishable -- by typing their password all over the place -- all the time, not even counting the poor default password hygiene most users have. This is one of the reasons U2F/WebAuthn is so incredibly valuable.
- amaccuish 8y agoI love SAML (not the XML part), it gives me one place where I can concentrate. My SSO first tries kerberos (if they've logged into their Windows machine using AD), x509 for smartcards, and if all that fails, username+password+totp. Password login is blocked without a TOTP token provisioned. Also it's one place I can stick fail2ban rules.
- angry_octet 8y agoAgree, SSO failures train people to type their domain password everywhere. Also used for proxy login, sent out via SMBv1 etc. A jumpbox with 2FA might be workable. Servers only accept logins from the jumpboxes, but you don't have to get 2FA working on them. Essentially it's an internal VPN gateway. (Be on the lookout for the knobheads in IT that set up parallel login mechanisms without 2FA, like mounting the file share, virtual desktop logins from the hypervisor, Kerberos auth.)