Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade to v2 breaks existing 2fa logins (internal error) #12

Closed
dvdfabian opened this issue Feb 6, 2019 · 3 comments
Closed

Upgrade to v2 breaks existing 2fa logins (internal error) #12

dvdfabian opened this issue Feb 6, 2019 · 3 comments

Comments

@dvdfabian
Copy link

dvdfabian commented Feb 6, 2019

Hello,

I have just upgraded syspass to the newest version and everything seems to work fine except for the 2fa plugin. After installing the v2 version and enabling it in the admin menu, nobody is able to log in because the 2fa plugin outputs internal error on every log in attempt.

The reason for this is a change in IV processing for existing users/configurations. When the user attempts to verify a PIN, syspass will load the corresponding IV from the DB. In the old version, this raw IV is then encoded using Base2N and then passed to the google authentication. In the new version, the raw IV is sent directly to the google authenticator which raises an exception (Google2FA.php, line 100) since the raw IV contains invalid base32 characters, e.g. 5718d5e75278.....d3dfbdd4c9a.

To fix this, one has to emulate the old behavior and add this to AuthenticatorService.php:

    public static function verifyKey(string $key, string $iv)
    {
        $base32 = new Base2n(
            5,
            'ABCDEFGHIJKLMNOPQRSTUVWXYZ234567',
            false,
            true,
            true
        );
        $iv = substr($base32->encode($iv), 0, 16);
        return Google2FA::verify_key($iv, $key);
    }

After this change to verifyKey(), everything starts working.

Best regards,

David Fabian

@nuxsmin
Copy link
Member

nuxsmin commented Feb 9, 2019

Hello, it's a nice hack, but unfortunately it will break current implementations in which old data do not exist. The root of this issue is that the old implementation stored the IV in raw mode, so it need to be encoded into base32 before checking, but the current one does store it in base32, so no encoding is needed when checking it.

I'll try to fix it by upgrading the old data instead.

Thanks for your contribution David!

Best regards.

@dvdfabian
Copy link
Author

Yes,

the best solution would be to update the data during DB update. You are correct that my fix breaks the new implementation (I came across it today). In the meantime, I updated my hack to this

        try {
            return Google2FA::verify_key($iv, $key);
        } catch(\Exception $e) {
            $base32 = new Base2n(
                5,
                'ABCDEFGHIJKLMNOPQRSTUVWXYZ234567',
                false,
                true,
                true
            );
            $iv = substr($base32->encode($iv), 0, 16);
            return Google2FA::verify_key($iv, $key);
        }

Best regards,

David Fabian

@nuxsmin
Copy link
Member

nuxsmin commented Dec 21, 2019

Solved ;)

@nuxsmin nuxsmin closed this as completed Dec 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants