2fa.confirm middleware do not attach to POST login route. about twofactor

[DarkGhostHunter]

Seen the test, the test suite won't break, which means... I have to add a new test.

[DarkGhostHunter]

I just deleted 15 paragraphs to just say this:

Yes, a bug.

You see, the middleware works over TOTP, which itself works over an authenticated user. If there is no authentication, it should fail, even if the guest user will never be able to confirm, but that's the principle.

Fix incoming? Yes. When? The café opens tomorrow so I can sap wifi.

[denydias]

LOL! Been there, done that.

I thought I was crazy because your documentation is very clear on middleware('2fa.confirm') usage, including some examples with POST routes that should have worked just like I supposed they would. When it didn't and I was forced to override Auth\LoginController@login, then I feel something might be wrong.

No worries about when, Italo! My dirty fix works for now, so I have plenty of time to wait for your magic. If I only had a little bit more time on hands, I could even provide a PR for you... unfortunately this is not the case atm.

Thanks a lot for the quick response! Have a nice week and drink a good coffee while enjoying free wifi.

[DarkGhostHunter]

Now I remember it's the same functionality than the prior version. Which version where you on?

Also, it won't fix your login. If the middleware requires the user to be authenticated, you will get the message "two-factor required" forever because the credentials won't reach the login at all.

An alternative would be two to make catch the InvalidCodeException and return a response indicating the TOTP failed.

[DarkGhostHunter]

Since I can't fix this, let me recommend you to this awesome LoginRequest courtesy of Laravel Breeze (is what I use for). You can just copy the file into your proyect.

Add the secret sauce as attemptWhen():

$attempt = Auth::attemptWhen(
    $this->only('email', 'password'),
    TwoFactor::hasCodeRoFails(),
    $this->boolean('remember')
);

if (! $attempt) {
    // ...
}

Then authenticate once it hits the controller.

public function login(LoginRequest $request)
{
    try {
        $request->authenticate();
    } catch (InvalidCodeException $e) {
        return 'Two Factor code is required to proceed';
    }
}

[denydias]

My versions from composer:

{
    "php": "^8.1",
    "laragear/two-factor": "^1.0",
    "laravel/framework": "^9.1"
}

Yeah, I was thinking about it and you're right. No cookies for me. If I understood it right, there's no way to implement the same behavior as the old EnforceTwoFactorAuth unless I implement it myself. The requirement here is to have a way to check if an about to be logged in user (we know user email) has 2FA enabled so the TOTP entry form could be displayed.

PS: I was about to send the text above and your suggestion popped in. I will try it... Thanks again, @DarkGhostHunter!

[denydias]

Out of curiosity, why you removed that feature? Maybe the listener was too aggressive, but the feature it provides is pretty handy.

[DarkGhostHunter]

Because was a security risk.

Credentials (password) are not to be saved somewhere. When you input your password, it saved it permanently in the view, meaning, anything could read the view and get your password. At that time, it was the only way to make the login hassle-free.

[denydias]

Sure. It is a security risk indeed.

But using encrypted connections mitigates that risk as the plain-text counterparts of users credentials will be available only to the UA and nowhere else in the loop. Of course there are MITM attacks that might obtain that data, but so is spoofing, phishing or even social engineering attacks capable to do so even if credentials are not presented to 2FA view. In the end it's all about compromises.

Maybe that functionality can return only if a secure protocol is in place, what's pretty usual these days.

Anyway, thanks for the reply and the suggestion of Breeze's LoginRequest. I'm working on it right now and looks promising.

Have a great week!

[DarkGhostHunter]

Sure. It is a security risk indeed.

But using encrypted connections mitigates that risk as the plain-text counterparts of users credentials will be available only to the UA and nowhere else in the loop. Of course there are MITM attacks that might obtain that data, but so is spoofing, phishing or even social engineering attacks capable to do so even if credentials are not presented to 2FA view. In the end it's all about compromises.

Maybe that functionality can return only if a secure protocol is in place, what's pretty usual these days.

Anyway, thanks for the reply and the suggestion of Breeze's LoginRequest. I'm working on it right now and looks promising.

Have a great week!

I honestly don't think it's gonna come back as it was. I also tried flashing the credentials into the session, but that way there you can't add them to the incoming request... except using the middleware and flashing the session credentials into the request you have to capture after their are valid... 😴

[denydias]

It's comprehensible, Italo. I for one support your decision to remove that feature for good. If a developer (like me) wants that function back, it's up to him to implement it as well as facing the responsibility on doing so. As the maintainer of such a security sensitive module, you're 100% right on your reasoning to avoid security risks introduced by your code... plus loads of legal reasons to back you up. 😉

[padre]

@denydias I also had to solve it in a similar way :-(