[simongray]

NemID, the previous national 2-factor solution, used a small card with rows of pre-printed single-use codes. When you logged in to a bank or a public sector website, it would ask for a random code at a specific row and column number. Once the system registered that you had just a handful of codes left, a new card would be sent to you via snailmail. It worked fine for the time.

The current system, MitID, depends on smartphones, though you can get an an external key generator as a backup too.

[xorcist]

The big drawback of one time passwords is that it doesn't protect against man-in-the-middle attacks such as phishing, which is in practice one of the most common attacks on systems of this scale.

The logistics operation involved in distributing codes is also very expensive and inflexible. You may need to authenticate payments a dozen times in an hour one day, when you are on a farmers market which doesn't take card payments or you are out dining with friends, and another day not at all.

Given all this, a good old public key infrastructure makes sense. But that is unfortunately also usually the first step to a complexity explosion.

[LeonidasXIV]

> The big drawback of one time passwords is that it doesn't protect against man-in-the-middle attacks such as phishing, which is in practice one of the most common attacks on systems of this scale.

This is true and was definitely a criticism of the old system, where websites would open the NemID iframe and ask you for your username, password and a specific indexed OTP code, without providing any authentication to you. You only notice something weird if it asks you for an the index of a code that is not on your card but maybe the scammer is lucky and guesses an index that you have and then they can use that phished username/password/OTP triple to perform an unauthorized action.

The new system is slightly different, because if you use the mobile phone authentication it will send you a notification to your phone, but if you use the (bespoke, non-standard) OTP dongle it still does not authenticate itself towards the user. However the codes are now time-based so if they collect an OTP code they can only use it in a ~30s window, so the phished credentials have to be used immediately.

[timoth]

> You may need to authenticate payments a dozen times in an hour one day, when you are on a farmers market which doesn't take card payments or you are out dining with friends, and another day not at all.

It's very unlikely people would need to mess about with MittId/BankID if they can't use card payments at a market. Firstly, if they're doing the almost-unheard-of clunky approach of using their mobile banking app to make a bank transfer, it would probably be authorised using their touch/face ID instead of BankID/MittID. But far more likely, they'd use one of the ubiquitous mobile payment apps: Vipps (Norway), Swish (Sweden) or MobilePay (Denmark).

[optionalsquid]

> The logistics operation involved in distributing codes is also very expensive and inflexible. You may need to authenticate payments a dozen times in an hour one day, when you are on a farmers market which doesn't take card payments or you are out dining with friends, and another day not at all.

Neither of the scenarios you describe would require you to authenticate using MitID: Peer-to-peer payments in Denmark are typically done using the app MobilePay, which only requires MitID authentication during setup. And you never need MitID authentication when paying in person, at most you'll need your card's pin-code

[LeonidasXIV]

Yeah but functionally it is the same. If the website is down it doesn't matter if I got the OTP code from a piece of paper or the dongle.