There is a Migrate from Google+ Sign-In howto for web apps.

The other component of that report is that there are 32,768 low-entropy "2048-bit" RSA keys which Debian systems generated until ~2008:

See https://hackerone.com/reports/474897, which suggests that ssh-keygen -l ... ("Show fingerprint of specified public key file.") is probably a pretty good starting point for ssh --is-this-a-valid-public-key:

Since T13227 has an actual realtime deadline, that's probably a good time to take care of this, too.

This can be implemented as a third-party extension. We're unlikely to ever pursue it upstream without customer interest.

I'm going to merge this into T12738. Although that task primarily discusses Nuance as a Phacility support tool and we ended up building a standalone Support tool instead, I generally believe Nuance is the most likely pathway for interactions falling under the general "helpdesk" umbrella.

I'm going to merge this into T12738. Although that task primarily discusses Nuance as a Phacility support tool and we ended up building a standalone Support tool instead, I generally believe Nuance is the most likely pathway for interactions falling under the general "helpdesk" umbrella.

I'm going to merge this into T12738. Although that task primarily discusses Nuance as a Phacility support tool and we ended up building a standalone Support tool instead, I generally believe Nuance is the most likely pathway for interactions falling under the general "helpdesk" umbrella. That is, the future for these use cases mostly looks like "lightweight/external users interact with Nuance, then staff triage issues into other objects like Tasks that only real users interact with", not "lightweight/external users interact with every application and every application gains support for email/external/grey interactions".

See PHI500 and T13179. Recent versions of SSH support passing the key fingerprint to the AuthorizedKeysCommand by specifying it like this:

I expect Google to expose a similar solution to Duo soonish (if you use Android and try to login to Google, MFA is just like Duo now).

Yes the exact text from the announcement about the intermittent failures states:

I received email from google announcing the deprecation few days ago. In the announcement they stated that they'll introduce intermittent failures on responses from the G+ API as soon as 01/2019.

The original request focused on OTP, not U2F, but I think the amount of configuration required by OTP and the lack (?) of a pathway on mobile make it a better candidate for third-party integration than first-party integration. If we were supporting OTP in the upstream I'd want to run a first-party verification service so we aren't dependent on Yubikey's service, but the whole thing seems very messy and very bound to the Yubikey stack. It also looks (?) like Yubikey OTP and Yubikey U2F aren't linked to the same key (I think?) so you can't use U2F on one device and then fall back to OTP on mobile, even if you want to type in 44 characters? You have to enroll OTP and U2F separately.

This browser doesn’t support the FIDO U2F standard yet.

After the stack of changes under D19897 land:

Sorry, yeah, I meant T6703.

I believe that instead of T7667 you meant to write T6703.

I think we're going to fix this with T7667 instead. Binding to a particular domain creates headaches if you actually move the LDAP server, and unlocked authentication creates a lot of other problems that we can't address in a similar way.

This is conceptually easy but we have no outstanding requests from customers.

At this point, I don't anticipate this ever coming upstream. This is probably a good candidate for third-party maintenance after T5055.

This doesn't seem to be cropping up terribly often and I think this use case is fairly weak.

Presuming something fixed this.

This might happen eventually, or as a side effect of T7303, but the use case here is pretty narrow and there's currently no customer interest so I don't currently anticipate building it.

There are two flavors of this:

Password management is in good shape after T13043 , and this would now be fairly easy to implement in a general way by adding a check in PhabricatorAuthPasswordEngine->isUniquePassword().

We don't validate that private keys in Passphrase are really usable private keys.

Add a temporary token revoker.
Add a session revoker.
Add an SSH key revoker.
Add a password revoker.
Add a VCS password revoker.

I believe this has been supported since D11543, in 2015. Specifically, log.ssh.format supports %k, and it appears to work as expected.

See D17458 for the previous, narrower case of token revocation in response to Heartbleed (T12313).