Kysymys:
Varmennepohjainen todennus vs. käyttäjänimen ja salasanan todennus
Stefany
2011-05-06 18:35:04 UTC
view on stackexchange narkive permalink

Mitkä ovat varmenteeseen perustuvan todennuksen edut ja haitat käyttäjänimen ja salasanan todennukseen nähden? Tunnen joitain, mutta haluaisin kiittää jäsenneltyä ja yksityiskohtaista vastausta.

PÄIVITÄ / p>

Olen myös kiinnostunut tietämään, mihin hyökkäyksiin he ovat alttiita, esim kuten toistaiseksi mainittiin raakaa voimaa, vaikka todistuksissa ei mainita mitään ... entä XSRF? Varmenteen odotetaan olevan lyhyempi käyttöikä ja se voidaan peruuttaa, kun salasana elää kauemmin, ennen kuin järjestelmänvalvojan käytäntö pyytää sitä muuttamaan ...

Seitsemän vastused:
#1
+96
Thomas Pornin
2011-05-06 20:05:59 UTC
view on stackexchange narkive permalink

1. Käyttäjät ovat tyhmä

Salasana on jotain, joka mahtuu käyttäjän muistiin, ja käyttäjä valitsee sen. Koska todennuksessa on kyse käyttäjän fyysisen henkilöllisyyden vahvistamisesta etänä (todentajan näkökulmasta), käyttäjän käyttäytyminen on välttämättä mukana prosessissa - salasanat kuitenkin riippuvat käyttäjän osasta, joka on tunnetusti keskinkertainen turvallisuuden, nimittäin aivojensa käsittelyssä. Käyttäjät eivät yksinkertaisesti ymmärrä, mistä salasanan entropia on kyse. En syytä heitä siitä: tämä on tekninen aihe, erikoistuminen, josta ei voi realistisesti tulla "järkeä" lähiaikoina. Toisaalta fyysisen tunnuksen turvallisuus on paljon "konkreettisempaa", ja tavallisista käyttäjistä voi tulla varsin hyvä siinä. Evoluutiolaiset kertovat, että ihmiset on valittu positiivisesti tähän viimeisen miljoonan vuoden ajan, koska ne, jotka eivät kyenneet pitämään piikivityökalujaan, eivät selvinneet tarpeeksi saadakseen jälkeläisiä. miten käyttäjät ajattelevat salasanoja - vain siksi, että nämä käyttäjät käyvät myös elokuvissa. Arkkivihollisella on poikkeuksetta lyhyt salasana, ja hän vain rakastaa kerskua siitä ja jakaa vihjeitä aina kun pystyy. Ja aina brittiläinen salainen agentti arvaa salasanan ajoissa deaktivoida fuusiopommin, joka oli istutettu kuningattaren suosikkikukkapenkkiin. Elokuvat näyttävät vääristyneeltä, liioitellulta todellisuudelta, mutta ne edustavat silti sitä henkistä perustasoa, jolla keskimääräiset käyttäjät toimivat: he kuvittelevat salasanojen tarjoavan turvallisuutta olemalla "nokkelampi" kuin hyökkääjä. Ja aina useimmat epäonnistuvat siinä.

"Salasanan voimakkuutta" voidaan parantaa jonkin verran pakollisilla säännöillä (vähintään kahdeksan merkkiä, vähintään kaksi numeroa, vähintään yksi iso ja yksi pieni kirjain ...), mutta käyttäjät pitävät näitä sääntöjä taakkana, ja joskus syntymättömän vapauden ylittämättömänä rajoituksena - joten käyttäjien on taisteltava sääntöjä vastaan ​​suurella luovuudella alkaen perinteisestä salasanan kirjoittamisesta muistilappuun. Useimmiten salasananvahvistussäännöt palavat täten.

Toisaalta käyttäjätodistukset tarkoittavat tallennusjärjestelmää, ja jos järjestelmä on fyysinen laite, jota käyttäjä kantaa talonsa tai autonsa avaimilla , sitten turvallisuus riippuu (osittain) siitä, kuinka hyvin tavallinen käyttäjä hallinnoi fyysisen objektin turvallisuutta, ja he tekevät yleensä hyvää työtä siinä. Ainakin parempi kuin hyvän salasanan valitsemisessa. Joten se on varmenteiden suuri etu.

2. Varmenteet käyttävät epäsymmetristä salausta

Asymmetria tarkoittaa roolien erottamista. Salasanalla kuka tahansa, joka tarkistaa salasanan, tietää jossain vaiheessa salasanan tai salasanaa vastaavat tiedot (no, se ei ole täysin totta PAKE -protokollien tapauksessa). Käyttäjän varmenteilla varmenteen myöntää varmentaja, joka takaa yhteyden fyysisen henkilöllisyyden ja julkisen salauksen avaimen välillä. Todentaja voi olla erillinen entiteetti, ja se voi vahvistaa tällaisen linkin ja käyttää sitä käyttäjän todentamiseen ilman mahdollisuutta esiintyä käyttäjänä.

Pähkinänkuoressa tämä on varmenteiden kohta: erottaa ne, jotka määrittelevät käyttäjän digitaalisen identiteetin (eli kartoituksen tekevän kokonaisuuden fyysisestä identiteetistä tietokonemaailmaan), niistä, jotka todenna käyttäjät.

Tämä avaa tietä digitaalisiin allekirjoituksiin , jotka johtavat kiistämättömyyteen. Tämä kiinnostaa erityisesti pankkeja, jotka ottavat rahoitustilauksia verkkoasiakkailta: heidän on todennettava asiakkaat (kyse on rahasta, josta puhumme, erittäin vakava asia), mutta he haluaisivat saada vakuuttavan jäljen tilauksista - tässä mielessä: tuomari olisi vakuuttunut. Pelkällä todennuksella pankki saa jonkin verran varmuutta siitä, että puhuu oikean asiakkaan kanssa, mutta se ei voi todistaa sitä kolmansille osapuolille. pankki voisi rakentaa väärennetyn yhteyskoodin, joten se on aseeton asiakasta vastaan, joka väittää olevansa pankin itse kehystämä. Digitaalisia allekirjoituksia ei ole heti saatavilla, vaikka käyttäjällä olisi varmenne; mutta jos käyttäjä voi käyttää varmennetta todentamiseen, suurin osa kovasta työstä on tehty.

Lisäksi salasanat ovat luonnostaan ​​alttiita tietojenkalasteluhyökkäyksille, kun taas käyttäjän varmenteet eivät ole. Juuri epäsymmetrian takia: varmenteen käyttöön ei koskaan sisälly salaisia ​​tietoja paljastamista vertaiselle, joten palvelimena esiintyvä hyökkääjä ei voi oppia mitään arvokasta tällä tavalla.

3. Varmenteet ovat monimutkaisia ​​

Käyttäjäsertifikaattien käyttöönotto on monimutkaista ja siten kallista:

  • Sertifikaattien myöntäminen ja hallinta on täysi mato, kuten mikä tahansa PKI myyjä voi kertoa sinulle (ja todellakin, minä sanon sinulle). Erityisesti peruutusten hallinta. PKI on noin 5% salausta ja 95% menettelyjä. Se voidaan tehdä, mutta ei edullisesti.

  • Käyttäjäsertifikaatit tarkoittavat, että käyttäjät tallentavat yksityisen avaimensa jollakin tavalla "yksinoikeudella". Tämä tehdään joko ohjelmistolla (olemassa olevat käyttöjärjestelmät ja / tai verkkoselaimet voivat tehdä sen) tai käyttämällä omistettua laitteistoa, mutta molemmilla ratkaisuilla on omat käytettävyysongelmasi. Kaksi esiin tulevaa ongelmaa ovat 1) käyttäjä menettää avaimensa ja 2) hyökkääjä saa kopion avaimesta. Ohjelmistojen tallennus tekee avaimen menetyksestä uskottavan ongelman (viallisen kiintolevyn armoilla), ja avaimen jakaminen useiden järjestelmien (esim. Pöytätietokone ja iPad) kesken tarkoittaa joitain manuaalisia toimintoja, joita ei todennäköisesti ole suojattu hyökkääjiltä. Laitteistomerkit tarkoittavat laiteajurien koko sotkuista liiketoimintaa, mikä voi olla vielä pahempaa.

  • Käyttäjäsertifikaatti edellyttää suhteellisen monimutkaisia ​​matemaattisia operaatioita asiakaspuolella; tämä ei ole ongelma edes aneemiselle Pentium II: lle, mutta et voi käyttää joidenkin Javascriptin varmenteita, jotka on lyöty yleiseen verkkosivustoon. Sertifikaatti vaatii aktiivista yhteistyötä asiakaspuolen ohjelmistoilta, ja mainittu ohjelmisto on yleensä ergonomisesti epäoptimaalinen tässä asiassa. Tavalliset käyttäjät voivat normaalisti oppia käyttämään asiakassertifikaatteja HTTPS-yhteydelle verkkosivustoon, mutta hinnalla oppia sivuuttamaan satunnaiset varoitusikkunat, mikä tekee heistä paljon alttiimpia joillekin hyökkäyksille (esim. Aktiiviset hyökkäykset, joissa hyökkääjä yrittää syöttää heille oman väärennetyn palvelinsertifikaatin).

Toisaalta salasanapohjainen todennus on todella helppo integroida melkein kaikkialle. Sekoittaminen on tietysti yhtä helppoa; mutta ainakaan se ei välttämättä aiheuta supistamattomia lisäkustannuksia.

Yhteenveto

Käyttäjäsertifikaatit mahdollistavat roolien erottamisen, joita salasanat eivät voi tehdä. He tekevät niin kustannuksella lisäämällä joukko toteutus- ja käyttöönottokysymyksiä, mikä tekee niistä kalliita. Salasanat ovat kuitenkin halpoja sopia ihmismieliin, mikä tarkoittaa luonnostaan ​​heikkoa turvallisuutta. Jotkut huijaukset (jopa PAKE-protokollat ​​mukaan lukien) ja ennen kaikkea syyttämällä käyttäjää ongelmatilanteessa voidaan lieventää salasanojen turvallisuusongelmia (tiedämme, että tavallinen käyttäjä ei voi valita suojattua salasanaa, mutta mikä tahansa virhe edelleen hänen vikansa - näin pankit tekevät sen).

"käyttäjät ovat tyhmä" - ei. Käyttäjät eivät ole tyhmä. He ovat järkevästi tietämättömiä: heillä on parempaa tekemistä ajastaan ​​kuin salasanan entropian matematiikan oppiminen. On tärkeä ero (ja erittäin tärkeä ero ajattelutavassa, turvallisuusmiehille). Käyttäjät eivät myöskään ole järkevästi vaatimusten mukaisia: kuten Cormac Herley on väittänyt, koska käyttäjän turvallisuuden rikkominen on suhteellisen harvinaista, käyttäjien hyöty ajankäytöstä ärsyttäviin turvatoimiin on yleensä suurempi kuin aika, jonka siihen tarvitaan niin.
@D.W. Rakastan tätä termiä "järkevästi tietämätön"! Näen, että siitä on tulossa paljon käyttöä ...
käyttäjät ovat käyttäjiä. Käyttäjät ovat ensisijaisesti kiinnostuneita tehtävistään, joista osa toimii suojausalalla. Turvallisuus heikentää usein käytettävyyttä, ja käyttäjät eivät tarkoituksellisesti noudata omaa käytettävyyttään. Järjestelmän turvaaminen vaatii käyttäjien yhteistyötä. Yhteistyön saamiseksi heidän on ymmärrettävä, miksi erityisiä toimenpiteitä on käytössä. "Salasanat ovat turvallisempia, kun ne ovat pidempiä", mutta tyypillisillä hyökkääjillä on työkaluja, jotka ottavat salasanan, joka on enintään kahdeksan merkkiä, joten teimme vähimmäispituudeksi yhdeksän. (Tein kahdeksan merkin pituuden).
Ja annat PKI-varmenteen ... oi "tyhmälle käyttäjälle" ja luotat siihen, että he huolehtivat siitä ja eivät laita sitä jonnekin kuten yrityksen tiedostoja.
Salasanan vahvuus-argumentti on väärä.Säännöt, kuten vähimmäismerkkien, isojen kirjainten ja numeroiden vähimmäismäärä, eivät todellakaan tee paljon entropialle, vaan yksinkertaisesti helpottavat salasanojen murtamista, koska hyökkääjä voi tietää tarkalleen, millaisista salasanoista tulee, ja vaikeuttaa salasanan muistamista.käyttäjille. Tarralapulle kirjoitettu salasana on yhtä turvallinen kuin samanpituinen varmenne, kun kaikilla hyökkääjillä ei ole fyysistä pääsyä koneeseen.
Tilasin pörssinvaihdon äänestämään D.W: n kommenttia."Järkevästi tietämätön"!- erittäin kiva.
* "Salasanat ovat luonnostaan alttiita tietojenkalasteluhyökkäyksille, kun taas käyttäjän varmenteet eivät ole." * Anteeksi, miksi kukaan ei pysty kalastamaan minulle kopiota varmenteestani eikä kopiota salasanastani?
#2
+34
bethlakshmi
2011-05-07 00:50:06 UTC
view on stackexchange narkive permalink

  • Käyttäjänimi / Salasana
    • Pro : Helppo ottaa käyttöön - tarvitsee vain koodi ja suojattu tietovarasto. Tietoturvakäytännöstä riippuen voi luoda salasanoja automaattisesti tai pakottaa uudet käyttäjät luomaan niitä.

    • Pro : Helppo hallita - salasanan palauttaminen voi (joillekin) tietoturvakäytännöt) tehdään automatisoiduilla työkaluilla. Käyttäjän unohtaminen tai salasanojen vaihtamatta jättäminen on joko turvallisuusriski tai käyttökelpoisuus.

    • Huijaus : Hyviä salasanoja voi olla vaikea muistaa, mikä johtaa käyttäjien salasanojen uudelleenkäyttämiseen tai kirjoittamiseen.

    • Huijaus : Salasanatietovarastot ovat heikko kohta - jos tunkeilija saa salasanasäilön , hän saa emolatauksen.

    • Huijaus : Kaikki salasanansiirron osat voivat johtaa altistumiseen - verkkosivustot, jotka tallentavat salasanoja paikallisesti käytön helpottamiseksi, sisäiset palvelinkomponentit, jotka lähettävät selvässä, lokitiedostot COTS-tuotteissa, jotka tallentavat salasanoja selvään. Koska salaisuus on osa lähetystä, olet yhtä vahva kuin heikoin lenkkisi - altistumisen estäminen vaatii vakavia ponnisteluja, ja vaatimus on sekä käyttäjälle että järjestelmän kehittäjälle.

    Sertifikaatit:

    • Pro : Ei vaadi salaisuuden lähettämistä. Yksityisen avaimen todistus ei sisällä salaisia ​​tietoja - lievittää kaikenlaisia ​​tallennuksen / lähetyksen heikkoja kohtia.

    • Pro : Myönnetty luotetulta osapuolelta (CA ), joka mahdollistaa keskitetyn hallintajärjestelmän tilalle useissa sovelluksissa. Jos sertifikaatti menee pieleen, se voidaan peruuttaa. Salasanasuojaus on korjattava erikseen jokaiselle järjestelmälle, ellei jaettua tunnusta käytetä.

    • Pro : Kieltäytymättömyys on vahvempi - useimmissa salasanajärjestelmissä tapa, jolla käyttäjä alun perin todennetaan ennen tilin luomista, on melko heikko ja salasanan palautusmekanismit voivat tarjota toisen tekijän uskottavaa. Monien varmenteiden myöntämismuotojen avulla käyttäjän on paljon vaikeampaa sanoa, etteivät he ole heitä. Varoitus - olet silti vain yhtä hyvä kuin varmentajan myöntämiskäytännöt.

    • Pro : Palvelee muita tarkoituksia kuin vain todennusta - voi tarjota eheyden ja luottamuksellisuuden samoin.

    • Huijaus : Edellyttää edelleen salasanaa / PIN-koodia - melkein kaikki yksityisten avainten paritallennusmekanismit avataan sitten PIN-koodilla. Älykortilla voi olla peukkasuojaus ja lukitusominaisuudet raakan voiman estämiseksi, mutta se ei korjaa sitä, että käyttäjä kirjoitti PIN-koodinsa muistilapulle tietokoneen viereen, johon kortti on telakoitu. Joskus salasanaongelmat ilmaantuvat uudelleen pienemmässä mittakaavassa PKI: n kanssa.

    • Con : Infrastruktuurin monimutkaisuus - PKI: n luominen ei ole helppo tehtävä ja yleensä niin kallista. sekä käyttöönotossa että ylläpidossa, että sitä voidaan käyttää vain suurissa / kalliissa järjestelmissä.

    • Con : Varmenteen tilaraportointi ja päivitykset eivät ole helppoja - peruuttaminen vioittunut käyttäjän käyttäjätiedot ovat raskaita infrastruktuurin koon ja monimutkaisuuden vuoksi. Yleensä varmentaja luo CRL: n, jota voidaan järjestää OCSP-palvelimen sisällä tai ei. Sitten jokaisen sovelluksen tulisi tarkistaa jokaisesta sisäänkirjautumisesta CRL- tai OCSP-tila. Tämä tuo järjestelmään useita aikaviiveitä PKI-tunnistetietojen raportoinnin vaarantumisen ja sen ajan välillä, jolloin järjestelmään, joka luottaa kyseiseen tunnistetietoon, alkaa tosiasiallisesti estää pääsy. Tilan päivityksen nopeutta voidaan kiihdyttää - mutta järjestelmän monimutkaisemmilla kustannuksilla.

    Pari muuta muistiinpanoa:

    Varmenteen odotetaan olevan lyhyempi käyttöikä ja se voidaan peruuttaa, kun salasana elää kauemmin, ennen kuin järjestelmänvalvojan käytäntö pyytää sitä muuttamaan ...

    I olla eri mieltä lähtökohdasta. Järjestelmissä, joissa olen työskennellyt sekä salasanan että PKI: n tukemiseksi, salasanapäivityksen vaatimuksia koskeva käytäntö on PALJON lyhyempi kuin varmenteiden myöntämistä koskeva käytäntö. Peruuttaminen on erilainen mato - se on vähemmän todennäköinen yksityisen avaimen kompromissi. Koska yksityisen avaimen tietoja ei lähetetä järjestelmän kautta, näille tiedoille altistumisen riskin oletetaan yleensä olevan paljon pienempi kuin salasanalle altistumisen riski. Käytännön syistä salasanojen katsotaan olevan lyhyempiä.

    Olen kiinnostunut myös siitä, mihin hyökkäyksiin ne ovat alttiita, esim. Kuten toistaiseksi mainittiin raaka voima, vaikka sertifikaateissa ei mainita mitään ... entäs XSRF?

    Sekoitat omenoita ja appelsiineja täällä. Raa'at voimat voivat olla toteuttamiskelpoinen hyökkäys kumpaan tahansa todennustunnistetyyppiin - mutta XSRF on hyökkäys taustalla olevaan sovellustyyppiin, joka olisi mahdollinen todennusmekanismista riippumatta. Ellet tarkoita, että koska käyttäjänimi / salasana syötetään jonkinlaisella tekstiliitännällä, he voivat olla alttiita sivustojenvälisille komentosarjoille kyseisellä käyttöliittymällä.

    Yleensä (anteeksipyyntöjä virallisen terminologian puuttumisesta - minä yleensä etsiä tyypillisiä hyökkäystermejä, mutta minulla on vähän aikaa):

    • Raakaa voimaa - koska keskimääräisen salasanasi avaintila on pienempi kuin epäsymmetrisen avaimen, salasana on helpompi raakaa voimaa. Riittävän pieni avainkoko sertifikaatissa on myös raakaa voimaa kykenevä ja kyky raa'an voiman hyökkäysavaimille kasvaa CPU-ominaisuuksien myötä pakottaen rotakilpailun avainkoon kasvaessa.

    • Koulutettu arvaus - avaintilan kaventaminen kohtuulliseen arvausjoukkoon on helpompaa salasanoilla, eikä se ole niin ilmeistä useimmille epäsymmetrisille avainalgoritmeille, vaikka RSA-algoritmissa on heikkoja avaimia, joten riippuu siitä, miten iso salakirppu, jonka hyökkääjä on.

    • Sosiaalitekniikka - voidaan tehdä kummallakin tavalla, vaikka laitteistoon tallennetulla varmenteella sinun ei tarvitse hallita vain käyttäjän PIN-koodia, vaan myös laitteisto, joka tallentaa avaimen.

    • Hyökkäyksen sisäpuolella - tunnistetietojen hankkiminen järjestelmän sisältä ja sitten niiden käyttäminen laillisen käyttäjän jäljittelemiseen - riippuu. Jos salasanoja säilytetään turvattomasti, tämä on paremmin toteutettavissa salasanapohjaisessa järjestelmässä. Mutta jos saat hallinnan varmentajasta, voit antaa itsellesi laillisen varmenteen, ja se riippuu siitä, miten pääsyä valvotaan.

    • Mies keskellä - riippuu - mies keskellä voi siepata salasanan, jos salasanaa ei salata siirron aikana salausmekanismilla, joka ohittaa hänet. Se on mahdollista SSL / TLS: n kanssa. Keskellä oleva mies voi kuitenkin myös siepata PKI-siirron osia sen mukaan, miten PKI: tä käytetään. PKI-allekirjoitukset, joissa ei ole aikaa tai aikaleimaa, ovat avoimia keskellä olevan miehen replikointihyökkäyksille - hän voi lähettää siepatun viestin niin kauan kuin ei ole mitään tapaa kertoa, onko viesti oikea-aikainen tai ainutlaatuinen.

  • Luulen, että sillä on kuitenkin vaikutusta CSRF: ään. Se näyttää voittavan CSRF-sisäänkirjautumishyökkäykset, koska hyökkääjä ei voi lisätä omia kirjautumistietojaan sisäänkirjautumispyyntöön.
    #3
    +8
    Stephen
    2011-05-06 19:15:04 UTC
    view on stackexchange narkive permalink
    1. Käyttäjätunnukset ja salasanat
      • Kyse on siitä, mitä tiedät. Annat salaisen koodisanan todennettavaksi palvelun kanssa.
      • Tämä tarkoittaa, että jos se siepataan streamissa, sitä voidaan käyttää. Salaus käyttää sitä epätodennäköiseksi, mutta silti mahdollista. Joku voi tehdä miehen keskellä saadakseen salasanasi tai ottamaan vastaan ​​tietokoneen, joka saa todennuksen.
      • Käyttäjätunnusta ja salasanaa voidaan käyttää millä tahansa tietokoneella milloin tahansa. Tämä on huono asia, jos turvallisuudella on merkitystä, ja hyvä asia, jos saavutettavuudella on merkitystä. Pankille ... tämä on huono. Facebookilla sillä ei todellakaan ole väliä.
    2. Sertifikaatit
      • Sertifikaatit ovat hieman kehittyneempiä. Palvelin lähettää tietoja asiakkaalle ja asiakas allekirjoittaa tiedot ja lähettää ne takaisin. Tämä tarkoittaa, että palvelin ei tiedä yksityistä avainta milloin tahansa, joten vaikka palvelimen keskellä tai haltuunotettu mies johtaa heihin pääsyn, heillä ei ole avainta.
      • Sertifikaatit ovat kipu käyttää. Et muista niitä ja ne voidaan varastaa.

    Paras järjestelmä on yhdistelmä. Laitat avaimeen salasanan, jotta sinulla on kaksi tekijää. Jotain mitä tiedät (salasana) ja jotain mitä sinulla on (avain). Kuitenkin mitä enemmän turvallisuuden tasoja, sitä enemmän tuskaa se on. Se on suuri kompromissi kaikessa turvallisuudessa.

    #4
    +8
    zedman9991
    2011-05-06 19:27:59 UTC
    view on stackexchange narkive permalink

    Olen samaa mieltä Stephenin kanssa. Esität tutkimuksen kannalta kovan kysymyksen, koska kysymys ei yleensä ole vertailu toisiinsa. Hyvä tapa ymmärtää, miksi molempia on olemassa ja joita ei yleensä luokitella toisiinsa, on keskittyä käyttöön. Sertifikaatit on sidottu konetason avainasemiin, joten ne sopivat erinomaisesti koneiden väliseen todennukseen tiettyjen etukäteen suunniteltujen koneiden välillä. Salasanat sopivat hyvin ihmisille, koska olemme liikkuvia ja pyrimme todentamaan useista järjestelmistä tavalla, jota on vaikea ennakoida etukäteen. Joten sertifikaatit ovat tyypillisiä suunnitellussa laitteistopohjaisessa todennuksessa ja salasanat ovat hyviä mobiililaitteisiin perustuvaan todennukseen. Älykortti on loistava tapa lisätä varmenteeseen perustuva todennus liikkuvaan ihmiseen ja toinen tekijä prosessiin.

    "Sertifikaatit on sidottu konetason avainasemiin ja ne ovat siten erinomaisia ​​koneiden välisessä todennuksessa" tämä on esimerkiksi tieto, jonka olen unohtanut ajatellessani, joten +1 thx!
    #5
    +3
    yfeldblum
    2011-05-06 19:46:18 UTC
    view on stackexchange narkive permalink

    Salasana voi usein olla pakottamaton ja se voidaan suunnitella sosiaalisesti, koska koska sen omistajan on muistettava se, se on usein paljon yksinkertaisempi kuin salainen avain.

    Yksityinen avain ( riittävä lujuus - RSA: lle 2048 tai 4096 bittiä) ei voida pakottaa raa'asti. Ainoa tapa todentaa järjestelmään, joka vaatii julkiseen avaimeen perustuvaa todennusta, on pääsy ensin johonkin toiseen tietokoneeseen yksityisen avaimen hankkimiseksi. Tämä tuo ylimääräisen monimutkaisuuden mihin tahansa hyökkäykseen. Sosiaalinen suunnittelu ei auta saamaan henkilön paljastamaan salasanansa, koska salasana purkaa vain hänen yksityisen avaimensa sen sijaan, että antaisi hänelle pääsyn suoraan kohdejärjestelmään. Sosiaalisuunnittelu saada henkilö paljastamaan yksityisen avaimensa salasanansa kanssa on todennäköisesti paljon vaikeampi.

    Lisäksi salasanat lähetetään verkon kautta käyttäjän koneesta järjestelmään, jota käyttäjä haluaa käyttää. . Yksityisiä avaimia ei lähetetä verkon kautta, ei selkeässä eikä salatussa muodossa; pikemminkin lähetetään vain julkinen avain.

    Varoitan käyttämästä ilmausta "ei voida pakottaa julmasti".
    Saatan ymmärtää väärin, mitä tarkoitat, mutta eikö sosiaalinen suunnittelu poista yksityistä avainta suojaavaa salasanaa yhtä hyvältä, ellei paremmalta kuin salasanan hankkiminen tietylle palvelulle?
    Sekä salasanalla suojatun yksityisen avaimen että kyseisen avaimen salasanan haku on yleensä vaikeampi kuin yksinkertaisesti salasanan noutaminen. Kyllä, sosiaalinen suunnittelu on hyvä hyökkäys molemmissa tapauksissa, vain julkisen avaimen todennuksen tapauksessa on enemmän haastavaa vetää pois. Esimerkiksi yksityistä avainta ei voida helposti muistaa (ja useimmiten sitä ei tallenneta muistiin), puhumattakaan puhelimitse lukemasta, joka vaatii laajempaa sosiaalisen suunnittelun työtä sen saamiseksi.
    Ymmärrän mitä tarkoitat. Kaipasin lauseen "... ensin yksityisen avaimen saamiseksi" kokonaan.
    #6
    +1
    Martin
    2013-11-20 20:13:08 UTC
    view on stackexchange narkive permalink

    Näyttää siltä, ​​että unohdat, että verkkosivusto voi käyttää sekä varmenteita että salasanoja. Jos varmenteen saanut käyttäjä tulee, ovi avautuu. Ja jos hänellä ei ole varmentetta, hänen on kirjauduttava sisään nimen ja salasanan tavoin.

    Tällä tavalla kiinnostuneet käyttäjät saavat todistuksensa, kaikki muut tekevät sen vanhalla tavalla.

    #7
    +1
    Mat Carlson
    2013-11-20 23:07:07 UTC
    view on stackexchange narkive permalink

    Haluaisin lisätä vaihtoehdon - kertaluonteiset salasanalaitteet. Olen samaa mieltä muiden kanssa varmenteiden ja salasanojen eduista ja haitoista - OTP-laitteet edellyttävät joidenkin taustakomponenttien toimintaa, mutta mielestäni ne voidaan integroida ilman paljon vaivaa (Active Directory on hieman erilainen, mutta muita järjestelmät eivät ole liian kovia).

    Salasanan ja kertakäyttösalasanan yhdistelmä toimii erittäin hyvin. Voit käyttää yksinkertaisempaa ratkaisua, kuten Yubikey, jolla on salasana (vaaditaan USB- tai NFC-yhteys), tai näytetty koodifob.

    Molemmat vaihtoehdot on helppo lisätä Linux-pohjaisiin toimintoihin. Jos haluat tehdä sen Active Directory -palvelussa, sinun on ostettava ohjelmisto koodin käsittelemiseksi ja asennettava se jokaiseen AD-palvelimeen. Sitten käyttäjä syöttää salasanakentän alkuun OTP: n ja sitten tavallisen salasanansa. Sitä varten on mahdollista kehittää oma moduuli, mutta kustannustehokas kuin mitä olen nähnyt.



    Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
    Loading...