Visualizzazione dei risultati da 1 a 4 su 4
  1. #1

    [Generico] Gestire credenziali account utente in maniera sicura

    Scusate se il titolo non è molto indicativo...ma non volevo creare un titolo chilometrico.

    Ho creato un'applicazione desktop per last fm che richiede l'autenticazione dell'utente di last.fm.

    Per l'autenticazione ho usato un metodo da me ritenuto più sicuro, ovvero non chiedo user e pass direttamente all'utente, ma con il browser lo reindirizzo in una pagina speciale di last.fm e da li' l'utente conferma l'utilizzo dell'account da parte della mia applicazione.

    Capisco che questo è un metodo scocciante per l'utente, che durante il funzionamento del programma si vede reindirizzato al browser...

    Volevo creare un form dove l'utente inserisce nome utente e password...in realtà lo posso fare benissimo e se fossi malintenzionato potrei benissimo inviare le credenziali a un mio sito e così rubare l'account dell'utente. Questo vale sia per last.fm sia per qualsiasi altro servizio sul web che fornisce api (facebook, youtube ecc.)

    Da qui sorge la mia domanda: ma un metodo più sicuro per fare ciò ed evitare che io venga a possesso della password nuda (e non hashata in md5, come in effetti la richiede last.fm)??? Io pensavo che le Password Field delle varie GUI ritornassero la password hashata, e non la password vera.

  2. #2
    Non mi è chiara esattamente la domanda... anche se tu usassi un componente di terze parti che ti dà solo l'hash della password all'utente non cambierebbe nulla (e non avrebbe comunque modo di accorgersene): chi garantisce che le potenziali malefatte che potresti fare tu non le faccia il controllo in questione?

    Se la domanda è "perché i controlli password standard sono fatti così", ti direi:
    1. per semplicità: considera che il controllo textbox con password nasce credo con Windows 1 o 2, e stiamo parlando dei primi anni '90
    2. per flessibilità, dato che non tutti possono desiderare una particolare funzione di hash, e in alcuni casi serve comunque il plaintext (se ad esempio stai scrivendo un'applicazione di cifratura hai bisogno di avere la password in plaintext)
    3. se anche il controllo in questione funzionasse come dici tu, niente impedirebbe ad un programmatore di scriversene la sua versione graficamente identica ma che gli restituisce il plaintext (basta fare subclassing della normale editbox), quindi non servirebbe a niente dal punto di vista della sicurezza.
    Amaro C++, il gusto pieno dell'undefined behavior.

  3. #3
    Ok grazie hai risposto in maniera esauriente alla mia domanda.
    Originariamente inviato da MItaly
    chi garantisce che le potenziali malefatte che potresti fare tu non le faccia il controllo in questione?
    A questo ci avevo pensato anche io: beh in questo caso ci si affiderebbe "all'autorità" che ha fornito il controllo (.net framework, swing ecc.)
    Originariamente inviato da MItaly
    Se la domanda è "perché i controlli password standard sono fatti così", ti direi:
    1. se anche il controllo in questione funzionasse come dici tu, niente impedirebbe ad un programmatore di scriversene la sua versione graficamente identica ma che gli restituisce il plaintext (basta fare subclassing della normale editbox), quindi non servirebbe a niente dal punto di vista della sicurezza.
    E' vero, che stupido che sono...non ci avevo pensato


    grazie della risposta comunque

  4. #4
    Amaro C++, il gusto pieno dell'undefined behavior.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.