[HN Gopher] Lithuania: Students stop university from using only ...
___________________________________________________________________
Lithuania: Students stop university from using only proprietary
authentication
Author : ZacnyLos
Score : 113 points
Date : 2023-04-20 18:12 UTC (4 hours ago)
(HTM) web link (fsfe.org)
(TXT) w3m dump (fsfe.org)
| zvolsky wrote:
| I've lost some of my TOTP keys because Microsoft Authenticator
| prevents you from exporting your keys unless you sign up. Well
| done VGTU students.
| ajb wrote:
| Yes, it's annoying that Microsoft are doing this. I have an OTP
| app, most things support standard HOTP or TOTP so I only need one
| app. Azure seems to have started to insist that you use a
| Microsoft app or SMS.
| tinus_hn wrote:
| It's the old playbook of Embrace, Enhance, Extinguish.
| jmclnx wrote:
| Nice seeing this little victory, but a big one for the
| students.
|
| But to me is what M/S is doing with their WSL (and secure
| boot). They want to get to the point were Linux can only
| execute under Windows on new Laptops. The Companies that
| control Linux (yes, Linux is now pwned by corporate
| interests) do not care what really happens to Linux as long
| as Wall Street is happy.
| JAlexoid wrote:
| They went straight for Extinguish. Microsoft Authenticator is
| far from being any form of "Enchancement"
| DaiPlusPlus wrote:
| I use Azure with both Google Authenticator and Authy - the
| option to use a QR code to init a standard TOTP app is there,
| it's just not-immediately-visible.
|
| ...unless your AAD admin restricted the option to use standard
| TOTP and forced the use of MS Authenticator?
| Larrikin wrote:
| I asked our sysadmin at work to enable it and found out it is
| only an option for personal accounts. Business accounts force
| you to use the Microsoft authenticator app.
| comte7092 wrote:
| This is not true.
|
| Source: my workplace has it enabled for business accounts.
| DaiPlusPlus wrote:
| I have an Organizational account. I'm not sure where
| they're getting that from.
|
| UPDATE: This post from 2022 is MS's announcement of GA for
| TOTP and specifically mentions that you can use any TOTP
| app: https://techcommunity.microsoft.com/t5/microsoft-
| entra-azure...
|
| and the official docs here: https://learn.microsoft.com/en-
| us/azure/active-directory/aut...
|
| I see the article says you need Azure AD P1 or P2, so I
| guess if you have a non-MSA organizational account in an
| AAD without P1/P2 then you'll be stuck with MS
| Authenticator - so that might explain that.
| ajb wrote:
| Hmm I'm going to have another look. Maybe it's not
| supported in the onboarding flow but you can add one
| later? Thanks for the links!
|
| I know our admin well enough to know that he wouldn't
| have switched it off deliberately - he would be in the
| same boat as me.
| rft wrote:
| I have no experience with MS AAD, but I saw something similar
| with GWorkspace. The TOTP option is not shown by default, you
| need to add a security key (e.g. YubiKey) or maybe (never
| tested) an Android phone. You can then add a TOTP, remove the
| other method and continue using TOTP.
|
| Maybe MS AAD has something similar? Then temporarily using a
| throwaway profile on a phone might be enough to get around
| that.
| donalhunt wrote:
| There are viable attacks where adversaries MITM the TOTP / HOTP
| token which is one of the reasons IDPs have moved in the
| direction of protocols that need an active app (e.g. solutions
| like number matching).
|
| See https://techcommunity.microsoft.com/t5/microsoft-entra-
| azure... for additional context.
| zvolsky wrote:
| The article you linked talks about the MFA fatigue attack. TOTP
| is not vulnerable to this attack since it doesn't send a push
| notification approval request. Would you elaborate on the
| viable MITM attacks that are possible with TOTP and mitigated
| by an active authenticator?
| saltcured wrote:
| Stopping phishing-based MITM attacks is one of the main
| things addressed with FIDO/U2F/Webauthn versus TOTP. Imagine
| an imposter website that is impersonating the real relying
| party as part of a phishing attack.
|
| With TOTP, the user is relaying a short-term secret code from
| their authenticator into the relying party's UI. But there
| isn't any authentication step to ensure that the user is
| really interacting with the expected relying party, and there
| is a time window where this code can be replayed. Once the
| attacker has this code, they could initiate multiple
| authentications with the real relying party during that
| window (approximate 1-2 minutes).
|
| With Webauthn, the relying party origin is used as part of a
| cryptographic signing step by the authenticator. There is
| also a per-request salt to prevent replay attacks. The
| imposter website would not be able to initiate a useful
| authentication step with the authenticator, since it would
| not be able to impersonate the real origin to the
| authenticator protocol. The various push-based authenticator
| apps have the opportunity to offer similar security, since
| they can authenticate the relying party challenges, show the
| user a trustworthy challenge prompt, and ensure that the
| response is not usable for replay attacks.
|
| A different category of attack might be to compromise the
| user agent itself. Then real sessions could be hijacked to
| perform operations not intended by the user. The non-
| replayable responses can partially mitigate these attacks
| too. The user can be prompted in real-time to reauthenticate
| for high-value operations, and may notice spurious prompts
| when they were not intentionally doing such actions. However,
| fatigue can set in if the user has too many relying parties
| registered with an authenticator and/or too many challenges
| and/or have non-determinism between UI actions and
| challenges. Then, the user could be confused into approving a
| challenge for the hidden attack operation happening in the
| background between their own intended actions.
|
| AFAIK, the only way to fully protect against this would be to
| include details of high-value operations in the
| challenge/response signature and have a way to display this
| detailed context in a trustworthy prompt. I.e. a mobile phone
| authenticator might be trustworthy even with a compromised
| desktop browser. But if your mobile browser is compromised, I
| would suggest you also should not trust the authenticator app
| on the phone. A dedicated hardware authenticator with a
| screen could show you challenge context, even if the user-
| agent is trying to fool you. This would be an improvement
| over the typical security key that at most blinks an LED and
| leaves it to the user to guess what is being authenticated.
| Arnavion wrote:
| TOTP can also be safe against an impostor website if the
| TOTP implementation validates the domain name of the
| request before filling out the TOTP code. KeePassXC's
| browser extension does this, for example.
|
| Of course, if the impostor has hijacked the user's DNS
| request for the real website's domain name, and the
| impostor has presented a TLS cert for the real website
| issued by a CA the user trusts, then what I described will
| still leak the TOTP code. But in that situation WebAuthn
| would also be broken.
|
| The advantage WebAuthn has is that it's built into the
| browser, so the browser gets to enforce that the user isn't
| involved in ways that could weaken the security. With TOTP
| the browser has no way of knowing if it's a domain-name-
| checking implementation like KeePassXC or the user is copy-
| pasting codes from another program or another device
| without applying sufficient care.
| zvolsky wrote:
| You raise some valid points, but I don't think that
| Microsoft Authenticator implements FIDO/U2F/Webauthn. My
| point was that the number matching implemented by Microsoft
| Authenticator is no safer than TOTP.
| DaiPlusPlus wrote:
| TOTP doesn't perform mutual-authentication: a lookalike on-
| screen prompt can be used to capture individual codes from
| unwitting users.
| andix wrote:
| It should be easily possible to extend the TOTP standard, so
| you also have to enter a number, before you get the code.
|
| But I think it will always be possible to do some kind of real
| time MITM attack, where you trick a user into accepting your
| fraudulent login.
| dbg31415 wrote:
| [flagged]
| JAlexoid wrote:
| Okta actually supports the generic 2FA method. I have my
| company Okta account 2FA with Authy and SMS.
| hooverd wrote:
| Their options were SMS or an MS app. It's not hard to provide
| TOTP or security token support.
| ExoticPearTree wrote:
| Depending how the authentication service was set, there could
| have been a possibility to scan the QR code with any TOTP 2FA
| app and have it working.
|
| I guess that the university set up either the push
| notification feature or the numbers matching feature, which
| would render other TOTP compatible apps useless.
| yjftsjthsd-h wrote:
| > because whatever tool couldn't be run from 10+ year-old Linux
|
| Why... why would you assume that? (Why would a student even be
| running an obsolete distro?)
|
| Since it's too much for you to read the article yourself, allow
| me to pick out the highlights:
|
| > What raised concerns was that the system set up by VGTU only
| allowed two options for 2FA, Microsoft Authenticator (app
| notifications) and SMS.
|
| > Microsoft Authenticator is proprietary software, meaning that
| users are not allowed to study, share, and improve the code
| without restriction. In addition, the app was only available on
| two platforms: Android with Google Play services or iOS,
| meaning that people using alternative Free Software App stores
| were locked out. The alternative SMS option required users to
| share their phone number and personal information with
| Microsoft, which also made students uncomfortable.
|
| > They pointed out that the study agreement did not require
| them to have a working phone running Google Play services or
| iOS. According to Lithuanian law, educational institutions
| cannot discriminate against students on the basis of their
| social status or beliefs, and the University's 2FA restrictions
| could discriminate against students who refuse or are unable to
| install a proprietary application on their personal devices.
| yazzku wrote:
| Instead of 'guessing' and then taking the guess towards an
| incorrect over-generalization while bashing students along the
| way, you could have done two minutes of research:
|
| https://en.wikipedia.org/wiki/Time-based_one-time_password
|
| You must not use 2fa a lot if you didn't know that exists.
___________________________________________________________________
(page generated 2023-04-20 23:02 UTC)