Quali sono i pericoli (pratici) di scrivere il tuo metodo di accesso?

2

Mi è sempre stato detto che scrivere il proprio metodo di accesso (ad esempio, convalidare l'utente dato il nome utente e la password) è una cattiva pratica, e che si dovrebbero riutilizzare le librerie esistenti per quello. L'ho sempre creduto, ma sto cercando minacce pratiche in uno scenario del genere (C #). Il caso pratico che sto esaminando è la personalizzazione di un metodo di accesso per includere la convalida di un captcha. Non ho trovato alcuna libreria esistente per fare quella dentro la logica di autenticazione.

Una delle implicazioni della mia implementazione personalizzata è che il metodo di convalida non restituisce un bool, ma un altro tipo. Possa questo rappresentare un pericolo?

    
posta Michael 29.07.2014 - 08:55
fonte

3 risposte

6

Il pericolo è espresso nella legge di Schneier :

any person can invent a security system so clever that he or she can't imagine a way of breaking it.

L'unico modo in cui chiunque può verificare se un determinato sistema è sicuro è che molte persone intelligenti provano a romperlo per un lungo periodo di tempo. Non lo avrai con un sistema che hai fatto da solo.

    
risposta data 29.07.2014 - 11:52
fonte
1

...but I am looking for practical threats in such a scenario (C#)

Esistono numerosi modi per introdurre una vulnerabilità eseguendo il proprio login. Alcuni che vengono in mente:

Enumerazione utente - Ho visto persone che danno messaggi descrittivi quando l'accesso non riesce ("l'utente non esiste", "l'utente esiste, ma la password non era corretta", ecc.) invece di un messaggio generico di "accesso non riuscito".

Norme di blocco insufficienti - Ciò consentirebbe a un utente malintenzionato di utilizzare username / password bruteforce. Ciò è particolarmente pericoloso se si dispone della vulnerabilità di enumerazione degli utenti sopra menzionata.

Non esegui l'azione di accesso tramite HTTPS - Potrebbe consentire un attacco uomo nella centrale quando qualcuno effettua l'accesso.

Come ho già detto ci sono una serie di altre potenziali vulnerabilità che dovresti tenere d'occhio (SQLi, XSS, la lista continua), ma le tre sopra sono quelle comuni che ho visto negli accessi "roll your own" .

    
risposta data 30.07.2014 - 01:08
fonte
0

Ho insegnato a non "rollare il tuo" in situazioni in cui c'è già qualcosa scritto per fare qualcosa di simile. Se fossi in te, proverei a trovare qualcosa che ha dimostrato di funzionare e provare a costruire intorno o sopra quello.

    
risposta data 29.07.2014 - 13:53
fonte

Leggi altre domande sui tag