Sool, nonces ja IVs. Mis vahe on?

Paroolide ja kasutajate turvalisuse tagamiseks andmete krüptimiseks on mõned erinevad teed. Mida nad kõik tegelikult teevad? Kõigil neil algoritmidel on erinevad lähenemisviisid, nagu näiteks vikerkaaretabelid, arvutamiseelsete rünnakute vältimiseks.

Soolad, nonces ja IV on kõik krüptograafias kasutatavad ühekordsed väärtused, mis ei pea tingimata olema salajased, kuid tagavad siiski täiendava turvalisuse. Üldiselt eeldatakse, et need väärtused on ründajatele nähtavad, isegi kui neid on mõnikord võimalik peita.

Sool

Üldiselt kasutatakse soola paroolipõhistes süsteemides ja see ühendatakse enne töötlemist parooli esiosaga. Teisisõnu, kui soola poleks, võiks ründaja luua levinumate paroolide sõnastiku ja otsida autentijalt ainult algse parooli.

Soola kasutamine tähendab, et ründaja peaks iga võimaliku soolaväärtuse jaoks looma täiesti eraldi sõnastiku. Kui sool on piisavalt suur, muudab see sõnastiku rünnakud sisuliselt võimatuks.

Pipar

Pipar täidab soolaga võrreldavat rolli, kuid kuigi sool pole salajane (lihtsalt ainulaadne) ja seda saab säilitada räsitud väljundi kõrval, on pipar salajane ja seda ei tohi koos väljundiga säilitada. Tavaliselt on parooli lõppu lisatud ainult üks märk. Räsit ja soola hoitakse tavaliselt andmebaasis, kuid pipart tuleb hoida eraldi (nt konfiguratsioonifailis), et ründaja seda andmebaasi rikkumise korral ei saaks. Või visake pärast kasutamist lihtsalt ära. Tavaliselt soovite oma räsi jaoks lisada nii soola kui ka pipart.

Noncement („üks kord kasutatav arv”) on andmebitid, mis sisestatakse sageli krüptoprotokollidesse ja algoritmidesse, sealhulgas paljud sõnumi autentimiskoodid ja mõned krüptimisrežiimid. Selliseid väärtusi tuleks konkreetse krüptograafilise võtmega kasutada ainult üks kord. Tegelikult ei ole korduvkasutamine üldiselt keelatud, kuid korduskasutamise tõenäosus peab olema erakordselt väike.

Järjestikustel noomenitel on juhuslike nokkidega võrreldes mõned eelised:

  • Saate hõlpsasti garanteerida, et nobeleid ei korrata. Pange siiski tähele, et kui võimalik nonce-ruum on suur, pole see tegelikult probleem.
  • Paljud protokollid saadavad juba iga paketi jaoks kordumatu järjekorranumbri, nii et edastatud sõnumites saab ruumi kokku hoida.
  • Pakkumiste järjestikust järjestamist saab kasutada kordusrünnakute ärahoidmiseks, kuid ainult siis, kui kontrollite tõepoolest, kas noomen kasvab pidevalt. See tähendab, et kui igale sõnumile on lisatud nonss, võite öelda, kas kiri tuli õiges järjekorras, vaadates seda ja veendudes, et selle väärtus aina kasvab.

Kuid nonsi juhuslikkus aitab vältida rünnakuid, mis amortiseerivad sama süsteemi mitme võtme tööd. Üldiselt soovite, et teil oleks nii juhuslik kui ka järjestikune osa.

1. samm: klient algatab SCRAM-i autentimisseansi

2. samm: server väljastab väljakutse

3. samm: klient vastab tõendiga

Initsialiseerimisvektor

IV või algmuutujad on kindla suurusega sisend.

IV ja nonce kasutatakse sageli vaheldumisi. Põhimõtteliselt on IV aga nonss koos täiendava nõudega: see tuleb valida ettearvamatul viisil. See välistaks kõik järjestikused nonces, IV peab olema juhuslik.

BCRYPT

Me ei saa aga unustada ägedat kingitust, mille Ruby on Rails meile küberturvalisuse tagamiseks pakkus. bcrypt () on keerukas ja turvaline räsialgoritm, mille TheBSL projekt on välja töötanud paroolide rämpsustamiseks. Bcrypt Ruby pärl pakub lihtsat ümbrist paroolide ohutuks käitlemiseks. Tavaliselt läheb parool läbi bcrypt-algoritmi ja seejärel “soolatakse” teiseks turbekihiks.

Põhimõtteliselt tuleks kokkuvõtlikult öelda, et soolad ja ühendid peaksid olema juhuslikud ja mittetoimed on tavaliselt järjestikused, potentsiaalselt ühe komponendina juhusliku soolaga, kui ruumi on. Järjestikuste paelte korral peate tagama, et te ei kordaks kunagi ühte {võtit, paelte} sidumist. Kui teil pole krüptimismaagiat, on hea uurida andmete kaitsmiseks mitme algoritmi kasutamist.