| ▲ | lxgr 12 hours ago |
| How would you use a paper ID online? (Securely, i.e. not the insane thing of taking a selfie holding it or something similarly bizarre in an age of powerful GenAI.) |
|
| ▲ | simongray 12 hours ago | parent | next [-] |
| 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 12 hours ago | parent | next [-] | | 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. | | |
| ▲ | optionalsquid 7 hours ago | parent | next [-] | | > 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 | |
| ▲ | timoth 11 hours ago | parent | prev | next [-] | | > 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). | |
| ▲ | LeonidasXIV 12 hours ago | parent | prev [-] | | > 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. |
| |
| ▲ | LeonidasXIV 12 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | LeonidasXIV 12 hours ago | parent | prev [-] |
| The way it worked before was that you had basically a piece of paper with OTP codes and the website would prompt you for a very specific one. How that would've prevented this issue: not at all. If the login service is down, having the piece of paper with OTP codes is worthless as the problem is not getting the codes (I can still get MitID codes with the OTP dongle) but the authentication website. The previous system was just as centralized. |