What level of security does this offer, compared to, say, a traditional HTTPS login form using a username/password that's saved in the browser?
Come hai raccolto da altre risposte, HTTPS nasconde la richiesta stessa. L'URL completo non viene inviato quando ci si connette al server: la parte del documento dell'URL è impostata come una richiesta simile a questa:
GET /login/reallysecure/thisismypassword
o più tradizionalmente:
POST /login
con i parametri POST inviati più tardi nella richiesta HTTP sia in forma semplice sia come parte di un corpo mime multipart.
Una considerazione che probabilmente non hai pensato è che l'accesso all'URL è tipicamente loggato dai server Web, il che significa che in qualsiasi momento dovrai dire 3 giorni (aggiustare il criterio di conservazione dei log) vale la pena di login utente uno a pochi passi dagli amministratori di sistema. Mentre questo è indubbiamente immateriale poiché una modifica all'applicazione stessa potrebbe scaricare le credenziali di accesso ordinarie senza troppe difficoltà, ora c'è un ulteriore fattore di protezione: si esegue il backup dei log? Cosa succede se vengono rubati?
Peggio ancora, cosa succede se c'è un modo per manipolare il tuo server per restituire i log ad un client esterno? Si tratta di una grave violazione della sicurezza, ma a differenza della restituzione di un database di password che si spera utilizzi una buona tecnica di hashing per mitigare (ed è molto mitigato) l'impatto di questo, un URL non ha la stessa protezione - è semplicemente istantaneo accesso all'account in questione.
Questa è la fine lato server del rischio sul lato client che Thomas ha già evidenziato.