L'apparentemente semplice requisito di cifrare un campo di un database si trasforma in un viaggio attraverso tutto lo stack, dal db al front end.
Presentato il 20 aprile 2016 al meetup M&M MEAN Milano.
Sorgente degli esempi a https://github.com/pmontrasio/full-stack-cryptography/
Serverless chatbot: from idea to production at blazing speed
Full Stack Cryptography
1. “È fatta. Resta da cifrare un campo in una tabella, che sarà mai?”
Paolo Montrasio Giorgio Sidari
paolo.montrasio@connettiva.eu giorgio@sidari.it
2. Il problema
Applicazione web conclusa
Bisogna cifrare un campo di testo nel DB
Il campo deve essere decifrabile nel client inserendo la chiave
Facile? Anche Ulisse deve aver detto così partendo da Troia
4. Alternative
Cifratura simmetrica con chiave sul server → inutile
Cifratura asimmetrica, solo chiave pubblica sul server → OK!
Ma…
Si cifrano solo blocchi lunghi quanto la chiave
Meno il padding
10. Ma possiamo far finta che lo sia
Padding deterministico in base ai dati Math.random()
crypto.randomBytes()
JavaScript si è scordato di un Math.seed()
→ modulo esterno require(“seedrandom”)
14. Anche le cose più semplici
nascondono sorprese
Interoperabilità con il backend
Base64 Node → Base64 JS, OK
Base64 Ruby → Base64 JS, un n di troppo
15. Inserire la chiave privata nel browser, ogni volta: NO!
La seppelliamo in LocalStorage: NI
La sicurezza della crittografia JS nel frontend è dibattuta
18. Jsencrypt non decifra senza padding!
Cercare un altro modulo → non se ne trovano
Aggiungere la propria funzione
di decifratura → non una passeggiata
Dare la brutta notizia al cliente → qui è dove Ulisse ha perso tutti
i compagni supestiti
19. Il codice da modificare è
di facile comprensione �
Scriviamo la funzione
24. Paolo Montrasio Giorgio Sidari
paolo.montrasio@connettiva.eu giorgio@sidari.it
@pmontrasio @ideaferace
https://github.com/pmontrasio/full-stack-cryptography
Slide a https://connettiva.eu/full-stack-cryptography