Repository navigation
Replies: 1 comment
|
There's a PR open for basic HTTP Auth: #1750, basically a password that you set and the browser keeps in your cookies, or in case of API use, keep in your scripts. There's also been talk about button press for confirmation of changes (configuration changes and firmware updates). IMO TOTP is fairly abrasive and I'm afraid that people will disable (or rather: never enable it) if it gets in the way too much, so the idea was to look for something that can be set once and then never see it again. But this has been discussion point for years already. The problem is that you have to nudge people towards closing it down, as ideally each device should be locked down, at least for firmware updates. So I think the current idea (at least my current idea) is to at some point enable button press for confirmation, with a banner. And if people set a password, the banner goes away and the button confirmation goes away. |
Uh oh!
There was an error while loading. Please reload this page.
I recently learned about the TOTP authentication feature available in NerdOS on the NerdQaxe++, and I would love to see something similar added to AxeOS.
NerdOS on the NerdQaxe++ has implemented a similar feature that allows the user to pair an authenticator app using a QR code and then requires a 6-digit TOTP code before sensitive settings can be changed.
I think this would be a useful optional security feature for AxeOS, particularly for protecting settings such as:
Ideally, the normal dashboard and mining statistics could remain accessible without authentication, while changes to sensitive settings would require TOTP. An optional trusted/authenticated session could also avoid requiring a new code for every individual change.
One of my main concerns is preventing another device or user with access to the same local network from changing the miner's pool or payout settings.
Since NerdOS already has a working TOTP implementation on ESP32-based mining hardware, perhaps some of its implementation could be useful as a reference.
I understand that this would need to be implemented server-side for the relevant API endpoints rather than simply protecting the AxeOS UI, so that the authentication couldn't be bypassed by making API requests directly.
I would personally find this especially useful for newer Bitaxe hardware such as the Naja Duo.
Thanks for considering it, and thank you for all the work on AxeOS.
All reactions