Ho creato un flusso di login che autentica un’applicazione front-end (scritta in Vue.js) per recuperare la user_api_key di un utente Discourse, seguendo le linee guida scritte da @samqui.
L’autenticazione funziona, ma la mia preoccupazione riguarda l’archiviazione sicura della chiave privata. Al momento, la chiave privata è salvata localmente nel file .env e utilizzata per la crittografia/decrittografia del payload. Questo è un metodo sicuro per crittografare il payload e, in caso contrario, quali sono le alternative per un’applicazione JavaScript front-end?
Come in un’app Electron/Tauri? Non ho idea di cosa sceglieresti, immagino che abbiano qualche meccanismo per l’archiviazione sicura; forse, se hai fortuna, puoi usare Keychain su Mac e qualcosa di simile su Windows.
È un’applicazione web ospitata su un server. La preoccupazione è che il payload potrebbe essere intercettato se la chiave privata viene esposta. Sono consapevole che questa è una preoccupazione più generale legata alla crittografia JavaScript, ma chiedo per verificare se esiste una pratica più sicura per autenticare un’applicazione web da Discourse.
Il sistema delle chiavi API utente non è progettato per questo caso d’uso: se passi attraverso la procedura di generazione di una chiave privata e poi la memorizzi sul server per conto dell’utente, perché fare tutto questo giro? Meglio generare le chiavi direttamente lato server.
È molto difficile per me fornire indicazioni senza comprendere appieno qual è il problema reale, in modo molto più dettagliato. Perché non fornire semplicemente dei punti di accesso proxy nella tua applicazione web e gestire tutta l’autenticazione nell’app?
Dopo aver parlato con il mio collega @owengot, ecco una descrizione più dettagliata del problema.
Esiste un’applicazione web basata su Vue.js che non dispone di un proprio componente lato server attivo. Piuttosto, è un’applicazione web autonoma che utilizza l’API di Discourse, quindi in un certo senso Discourse funge da server. I casi d’uso includono sondaggi o moduli autonomi, in cui i contenuti vengono pubblicati nei topic di Discourse sotto l’account dell’utente. Sembra un’architettura piacevole per questi utilizzi poter creare un tale software senza componenti lato server personalizzati, quindi idealmente vorremmo evitare di fare qualsiasi cosa “lato server”.
Ora, ottenere una chiave API utente funziona come previsto, ma @owengot ha scoperto che il passaggio di generazione di una chiave privata in JavaScript richiede molto tempo (fino a 10 secondi, è semplicemente inefficiente in JavaScript…). Poi ha scoperto l’hack secondo cui la stessa chiave privata può essere utilizzata per più utenti, quindi l’ha archiviata in un file sul server web che ospita anche gli altri file statici dell’applicazione web (JS, CSS, ecc.). Questo la rende veloce… ma ora quella chiave privata è (1) condivisa e (2) archiviata in modo accessibile, con un URL pubblicamente raggiungibile. Questo sembra, umh, spaventoso
Quindi ho detto che dobbiamo chiedere al team di Discourse quali siano le implicazioni di sicurezza di questo hack. Vedo due alternative di base:
Se quella chiave privata è utilizzata “solo” per la crittografia del payload, potremmo accettarlo perché abbiamo anche la comunicazione crittografata tramite SSL/HTTPS.
Ma se conoscere quella chiave privata permette in qualche modo di calcolare la risultante chiave API utente che viene poi utilizzata per pubblicare sotto l’account di qualcuno su Discourse, ovviamente renderebbe questo hack inaccettabile.
Anch’io sono curioso al riguardo, dato che ho iniziato a utilizzare il software sviluppato da @owengot. Secondo quanto ha detto @tanius, pensi che questo sia un modo sicuro per farlo, @sam?
