Kysymys:
Onko julkisen avaimen käyttäminen kirjautumiseen SSH: hon parempi kuin salasanan tallentaminen?
Nick T
2011-05-17 19:16:44 UTC
view on stackexchange narkive permalink

Julkisen / yksityisen avaimen parin käyttäminen on melko kätevää kirjautumisessa suosituille isännöille, mutta jos käytän avainparia ilman salasanaa, onko se turvallisempaa (vai vähemmän turvallista) kuin salasana? Yksityisen avaintiedostoni ympärillä oleva turvallisuus on ensiarvoisen tärkeää, mutta sanoko, että maaginen yksityisen avaimen tiedostoni oli vain luettelo salasanoista eri isännöille, onko siinä eroa?

Ssh-avaimen halkeilevat bitit ovat todennäköisesti huomattavasti korkeammat kuin mikään, mitä käytät salasanalle.
Miksi avainparia ilman salasanaa? Miksi et käyttäisi salasanaa yksityisessä avaimessasi ja käytä ssh-agentia parempaan turvallisuuteen ja mukavuuteen?
Voit myös tutkia S / KEY-todennuksen käyttöä.
Katso myös http://security.stackexchange.com/questions/69407/why-is-using-ssh-key-more-secure-than-using-passwords
Vastaus osoitteessa https://security.stackexchange.com/questions/69407/why-is-using-an-ssh-key-more-secure-than-using-passwords on hieman sulavampi IMO.Mutta [@john's-vastaus] (https://security.stackexchange.com/a/3898/6499) on todennäköisesti kattavampi, ja se tulisi myös lukea ymmärtämistä varten.
Kuusi vastused:
#1
+86
john
2011-05-17 21:26:31 UTC
view on stackexchange narkive permalink

Vastaukseni on, että julkisten avainparien käyttö on paljon viisaampaa tekemistä kuin salasanojen tai salasanaluetteloiden käyttö. Keskityn asioihin, joita ei tunneta laajalti SSH-todennuksen eri muodoista, enkä näe muita vastauksia mainitsemasta niitä.

Ensinnäkin sinun on ymmärrettävä, että käyttäjän todennus on erilainen ja erillinen prosessi kuin suojatun kanavan perustaminen. Yleisesti ottaen tämä tarkoittaa sitä, että ensin palvelimen julkista avainta käytetään (jos se hyväksytään!) Suojatun SSH-kanavan rakentamiseen mahdollistamalla symmetrisen avaimen neuvottelu, jota käytetään jäljellä olevan istunnon suojaamiseen, kanavan salliminen luottamuksellisuus, eheyden suojaus ja palvelimen todennus.

After kanava on toimiva ja turvallinen, käyttäjän todennus tapahtuu. Kaksi tavallista tapaa tehdä se on käyttää salasanaa tai salasanapohjainen todennus toimii kuten voit kuvitella: Asiakas lähettää salasanansa suojatun kanavan kautta, palvelin tarkistaa, että tämä on todellakin tietyn käyttäjän salasana, ja sallii pääsyn. hyvin erilainen tilanne. Tällöin palvelimelle on tallennettu käyttäjän julkinen avain. Seuraavaksi tapahtuu, että palvelin luo satunnaisen arvon (nonce), salaa sen julkisella avaimella ja lähettää sen käyttäjälle. Jos käyttäjän on tarkoitus olla, hän voi purkaa haasteen ja lähettää sen takaisin palvelimelle, joka sitten vahvistaa käyttäjän henkilöllisyyden. Se on klassinen haaste-vastausmalli . (SSHv2: ssa käytetään jotain hiukan erilaista, mutta käsitteellisesti läheistä)

Kuten voitte kuvitella, ensimmäisessä tapauksessa salasana lähetetään tosiasiallisesti palvelimelle (ellei SSH käytä salasanahaastevastausta), toisessa yksityinen avain ei koskaan jätä asiakasta. Kuvitteellisessa tilanteessa joku sieppaa SSL-liikenteen ja pystyy purkamaan sen salauksen (käyttämällä vaarantunutta palvelimen yksityistä avainta tai jos hyväksyt väärän julkisen avaimen muodostaessasi yhteyden palvelimeen) tai sinulla on pääsy palvelimeen tai asiakkaaseen, salasanasi tunnetaan - julkisen ja yksityisen avaimen todentamisen ja haastevastausmallin avulla yksityiset tietosi eivät koskaan pudota hyökkääjän käsiin. Joten vaikka yksi palvelin, johon muodostat yhteyden, on vaarantunut, muut seitsemän avainta käyttävät suojaimet eivät olisi !

Julkisen avaimen parin käytöllä on muita etuja: Yksityistä avainta ei tule tallentaa asiakastietokoneesi selkeään tekstiin, kuten ehdotat. Tämä tietysti jättää yksityisen avaimen tiedoston vaarantumaan, kuten salaamaton salasanatiedosto tekisi, mutta on helpompaa purkaa (sisäänkirjautumisen yhteydessä) ja käyttää yksityistä avainta. Sen tulisi olla tallennettu salattuna , ja sinun on annettava yleensä pitkä salasana salauksen purkamiseksi aina, kun sitä käytetään.

Tämä tarkoittaa tietysti, että sinun on annettava pitkä salasana joka kerta, kun muodostat yhteyden palvelimeen, yksityisen avaimen lukituksen avaamiseksi - Siellä on tapoja. Voit lisätä järjestelmän käytettävyyttä todennustoiminnon avulla: Tämä on ohjelmisto, joka avaa avaimet nykyiselle istunnolle, kun kirjaudut esimerkiksi gnomeen tai kun ensin ssh asiakasohjelmaasi, joten voit vain kirjoita 'ssh remote-system-ip' ja kirjaudu sisään ilman salasanaa ja tee se useita kertoja, kunnes kirjaudut ulos istunnostasi.

Yhteenvetona voidaan todeta, että julkisten avainparien käyttäminen tarjoaa huomattavasti enemmän suojaa kuin käyttämällä salasanoja tai salasanaluetteloita, jotka voidaan kaapata, jos asiakas , palvelin tai turvallinen istunto on vaarantunut . Jos salasanaa ei käytetä (sen ei pitäisi tapahtua), silti julkisten avainten parit tarjoavat suojauksen vaarantuneilta istunnoilta ja palvelimilta.

Hmmm, luin kysymyksen uudelleen ja huomasin, että nimenomaan kysytään siitä, ettei yksityisavain ole salasanaa - en huomannut sitä kirjoittaessani vastausta. Tietysti on edelleen mahdollista käyttää edustajaa, joten salasanan käyttämättä jättäminen ei ole kovin fiksua.
Muokkasin vastausta vastaamaan oikeaa kysymystä (ilman salasanoja).
Yksityiset avaimet voidaan purkaa automaattisesti Ubuntussa, niiden salasanat salataan kirjautumissalasanallani, ja Ubuntu avaa ne minulle automaattisesti, kun kirjaudun sisään. Tämä on todella molempien maailmojen parhaat puolet, koska minulla on kätevä salasanaton avain salasanalla (melkein). jos kirjaudut sisään korkean tietoturvan tietokonejärjestelmään, se ei välttämättä ole riittävän turvallinen, koska kirjautumissalasanasi voi vaarantua melko helposti, joten avaimesi salasanat voivat vaarantua. Se on kuitenkin paljon parempi kuin avain ilman salasanaa.
Jos "salasanan käyttämättä jättäminen ei ole älykäs", niin miksi [OpenSSL-ohjeet] (http://www.openssl.org/docs/HOWTO/keys.txt) sanovat nimenomaan, että "voi olla hyvä asia vältä suojaamasta sitä salasanalla "? (Pitäisikö minun kysyä tämä itsenäisenä kysymyksenä?)
Osa tästä vastauksesta on vähän liian yksityiskohtainen ja johtaa harhaan. Publickey-todennuksen erottava piirre tässä yhteydessä on, että asiakas allekirjoittaa jotain yksityisellä avaimellaan eikä hänen tarvitse paljastaa salaisuutta prosessissa. SSH-2-julkisen avaimen todennus ei todellakaan käytä tässä vastauksessa kuvattua haaste-vastausprotokollaa. Asiakas allekirjoittaa arvon, jonka molemmat osapuolet johdattavat itsenäisesti osana symmetristä avainsopimusprosessia; katso RFC-4252, osa 7 (erityisesti "istunnon tunniste"). Molemmat osapuolet osallistuvat, eivätkä kumpikaan voi määrittää sitä.
Istuntotunnuksen käytöllä julkisen avaimen todennuksessa on mielenkiintoinen vaikutus, jota ei usein huomauteta: se tarjoaa ylimääräisen suojan keskellä olevan ihmisen hyökkäykseltä. Jos hyökkääjä suorittaa avaimenvaihdon erikseen kummallakin puolella, istuntotunnisteet (ID) ovat erilaiset. Palvelin vaatii allekirjoituksen ID: n kautta, jotta se voi olla yhteydessä hyökkääjään - mutta asiakas tuottaa allekirjoituksen vain sen puolella olevan tunnuksen yli. Hyökkääjällä ei ole mitään keinoa pakottaa heitä olemaan samanlaisia, eikä millään tavalla saada asiakasta tekemään mitään muuta. Haaste-vaste-protokolla ei tekisi tätä.
@RichardE.Silverman Ehkä sinun pitäisi ehdottaa muokkausta. Juliste ei todennäköisesti muokkaa itseään, koska hän ei ole ollut tällä sivustolla kolme vuotta.
#2
+16
Thomas Pornin
2011-05-17 19:27:18 UTC
view on stackexchange narkive permalink

Tallennettuun (pitkiin ja satunnaisiin) salasanoihin verrattuna tallennettu SSH-yksityinen avain tarjoaa saman suojauksen : asiat ovat turvassa niin kauan kuin yksityinen tiedosto pysyy yksityisenä.

Yksityinen avain on kuitenkin paljon kätevämpi , käytännöllisesti katsoen (tällä hetkellä SSH-asiakkaat tukevat sitä valmiina, toisin kuin muokattu salasanatiedosto, jota sinun on käytettävä manuaalisesti copy&paste) ja teoreettisesti (voit käyttää samaa avainta uudelleen jokaiselle isännälle, johon haluat muodostaa yhteyden, kun taas salasanaluettelo kasvaa lineaarisesti yhteydenotettujen isäntien määrän kanssa, ellet käytä samaa salasanaa uudelleen useille isännille, mikä on huono ).

Pelkään, että jotkut lukijat kaipaavat "pitkien ja satunnaisten salasanojen" vaikutuksia. Yksityisellä avaimella on paljon enemmän entropiaa kuin realistisella salasanalla (sanotaan ainakin 128 bittiä entropiaa, olettaen kunnollinen RNG; 10-ASCII-merkkisellä salasanalla on noin puolet siitä, paljon vähemmän, jos se on mieleenpainuva). Myös ihmiset käyttävät salasanoja paljon useammin kuin yksityiset avaimet. Joten käytännössä yksityisellä avaimella on turvallisuusetuja.
@Gilles: n epäsymmetrisillä avaimilla, kuten SSH: ssä käytetyillä avaimilla, on kaikilla vähintään 1024 bittiä entropiaa, ei 128. Asymmetrinen salaus edellyttää kuitenkin myös * enemmän entropiaa. 1024-bittinen epäsymmetrinen on heikompaa kuin 128-bittinen symmetrinen salaus. Kun joku yrittää karkottaa SSH-palvelinta, hänen on tehtävä se "hitaasti", jotta vältetään palvelunestohyökkäyksen luominen. Tämä tarkoittaa sitä, että salasanan, jossa on ~ 50 bittiä entropiaa, arvaaminen kestää satoja miljoonia vuosia. Mene nopeammin ja palvelin räjäytetään Internetistä hyökkäyksen ajaksi, ja sysadmin aikoo huomata / tutkia.
10-merkkisen salasanan karkean voiman käyttäminen edellyttää satoja biljoonia arvauksia sekunnissa, ja se vie vielä viikkoja. Mikään palvelin ei kykene vastaanottamaan mitään etäisyyttä lähellä monia SSH-kirjautumisyrityksiä. Muutama sata yritystä sekunnissa on realistisempi, mikä on liian hidasta ollakseen tehokas, ellei salasana ole kauhea. Jokainen tämän verkkosivuston lukija on tarpeeksi älykäs valitsemaan hyvän salasanan.
@AbhiBeckert Luulen, että sekoitat avaimen koon entropiaan. Avaimen tai salasanan rikkomisen ei aina tarvitse olla verkkohyökkäys: hyökkääjällä voi olla pääsy julkiseen avaimeen. Joka tapauksessa luulen, että menetit huomautukseni kokonaan: avainparin entropia, joka estää [vikoja] (https://www.schneier.com/blog/archives/2008/05/random_number_b.html), on aina paljon suurempi kuin mikään ikimuistoinen salasana.
@Gilles ja luulen, että sinulta puuttuu mielipiteeni, eli että kenenkään ei pidä käyttää muistettavia salasanoja tuotantopalvelimessa. Salasanojen tulee olla satunnaisia ​​kokonaislukuja, jotka on koodattava näppäimistöllä kirjoitettavilla merkeillä.
#3
+13
Bruno
2011-05-17 20:16:45 UTC
view on stackexchange narkive permalink

Se riippuu siitä, mitä uhkia harkitset.

Julkisen / yksityisen avaimen todentamisen pääkohde on olla antamatta salaisuuttasi edes osapuolelle, jolle autentikoit. Tästä syystä avainten käyttö on parempi, koska et koskaan lähetä salaa ulkopuolelle koneellesi.

Jos kuitenkin pidät uhkaa paikallisena ja jos et suojaa yksityisiä avaimiasi salasanalla, salasanaluettelon tallentaminen selkeästi tarkoittaa samaa kuin yksityisten avainten tallentaminen ilman suojausta.

Tästä syystä on hyödyllistä suojata yksityiset avaimet salasanalla ja käyttää työkaluja, kuten ssh-agent (mukavuuden vuoksi) ). OSX: ssä tämä voidaan integroida myös KeyChainiin, joten sinun ei tarvitse edes avata yksityistä avainta (sovellustasolla, vain suojausdemonemonitasolla) voidaksesi käyttää sitä SSH: n (lähinnä KeyChain) kautta ja tietoturvapalvelut huolehtivat ssh-agentista).

> Julkisen / yksityisen avaimen todentamisen pääkohde on olla antamatta salaisuuttasi edes osapuolelle, jolle aitoudut. Tästä syystä avainten käyttö on parempi, koska et koskaan lähetä salaisuuttasi koneesi ulkopuolelle. Eikö SSH tue haastesalasanan todennusta?
Tervetuloa Security.SE-sivustoon. Kuten olet ehkä huomannut, yhteisön eri jäsenet arvostelevat vastauksiasi. Jos olet lukenut usein kysytyt kysymykset (linkki sivun yläosassa), saat paremman kuvan siitä, miten voit lähettää viestejä tähän yhteisöön. Haluat myös keskittyä enemmän uusiin kysymyksiin sen sijaan, että kaivaisit vanhoja, joilla on erittäin äänestetyt ja hyväksytyt vastaukset.
... lisäksi lisäyksesi tähän vastauksena olisi ollut sopivampaa sijoittaa kommenttina. Selventävästä kysymyksestäsi SSH ei tue salasanahaasteen todennusta.
#4
+10
Karol J. Piczak
2011-05-17 20:12:57 UTC
view on stackexchange narkive permalink

Tärkein ero yksityisen avaimen ilman salasanaa ja pelkkätekstisen salasanan käytön välillä SSH-valtuutuksessa on valtuuttaminen jollakin omistamallasi ( yksityinen avain) tai jotain, mitä tiedät (muistamasi salasanasi). He ovat erilaisia ​​rotuja, mutta on vaikea sanoa, että yksi on viime kädessä parempi tai turvallisempi.

Valtuutuksesi valtuuttaminen hyökkääjällä on yleensä vaikeampi replikoida sininen - on helpompaa karkottaa / arvata yksinkertaisempi salasanasi kuin kopioida avain. Mutta sillä on suuri haittapuoli - nyt tärkeänä pidetään yksityisen avaimen pitäminen todella salassa . Jos käytät jotain, jonka tiedät vain sinä (tallennettu salasana), sen pitää olla helpompaa pitää sillä tavalla (ainakin teoreettisesti). Mutta jos sinun täytyy muistaa se, niin todennäköisesti käytät jotain ei niin monimutkaista.

Joten sinun on päätettävä, mikä on todennäköisempää - vahva yksityinen avain varastetaan tai ei niin vahva salasana arvata (tai hankitaan) jollakin muulla tavalla).

Tässä on yksi poikkeus - jos tarkoitat kysymyksessäsi, että tallennat todella pitkiä, monimutkaisia ​​ja satunnaisia ​​salasanoja salaisessa tiedostossasi yksityisen avaimen käyttämisen sijaan, luultavasti pieni ero näiden kahden välillä silti jonkin verran eroa (olen unohtanut osan, katso @john vastauksen saadaksesi mukavan kirjoituksen tästä ). Siinä tapauksessa molemmat ovat jotain sinulla , pidä se salassa -tyyppejä, mutta kysy sitten itseltäsi - miksi tehdä se ensinnäkin, jos yksityiset avaimet on suunniteltu varten? sinun tulisi pysyä yksityisissä avaimissa.

Huomaa myös, että nämä kaksi voidaan yhdistää triviaalisesti suojaamalla yksityinen avain salasanalla. Nyt tarvitset jotain, jonka tiedät * (salasana) päästäksesi johonkin, mikä sinulla * on * (yksityinen avain).
#5
+8
sarnold
2011-06-13 06:10:02 UTC
view on stackexchange narkive permalink

Viitatussa artikkelissa keskustellaan ssh-istunnon aikana kirjoitetuista salasanoista. Mielestäni se ja Richardin kommentit kannattaa pitää silmällä, mutta eivät enää usko itse vastaukseen. (Pidän edelleen mieluummin julkisista avaimista.)

Song, Wagner ja Tian ovat osoittaneet, että on mahdollista nopeuttaa raakaa voimaa käyttävien salasanojen hakua noin 50 kertaa käyttämällä ajoitustietoja ssh -istunnoista . Noack palasi tutkimukseensa ja löysi SSH2: n myös alttiina ajoitusanalyyseille.

Hyökkäys antaa kaksi oletusta:

  • Salasanan hajautus on käytettävissä raa'an voiman murtamiseen.
  • Hyökkääjä voi saada tarkat aikaleimat isäntien välillä lähetetyistä paketeista tai hankkia muuten ajoitustietoja.

Julkiset avaimet eivät ole vain käteviä, vaan myös turvallisempia tiettyjä uhkia vastaan.

Tämä kommentti on harhaanjohtava, ja kirjailija on voinut ymmärtää väärin Song ym. Työtä. Sitä sovelletaan vain, jos kirjoitat salasanasi SSH-yhteyden kautta vuorovaikutteisesti: esimerkiksi jos kirjaudut SSH: n etäkoneeseen, suorita sitten komento sudolla, jotta sinun on kirjoitettava salasana sudo-todennusta varten yhteyden kautta. Kun teet sen, näppäimistön väliset pakettien ajoitukset salasanaa kirjoittaessasi paljastavat salasanan tiedot. [jatkuu…]
Kysymys ei kuitenkaan koske "salasanasi kirjoittamista SSH: n kautta", vaan pikemminkin "SSH-salasanan todennusta", joka ei ole täysin yhteydessä toisiinsa. Kun todennat itsesi salasanalla SSH-palvelimelle (joko "salasanalla" tai "vuorovaikutteisella näppäimistöllä" käyttäjän automaattisella menetelmällä), kirjoitat salasanasi paikallisesti - ei SSH: n kautta. Salasana lähetetään yhtenä pakettina palvelimelle. Ajoitushyökkäyksellä ei ole merkitystä tässä. Katso: http://archive.oreilly.com/pub/a/linux/2001/11/08/ssh_keystroke.html
@RichardE.Silverman, kiitos. Olen muokannut vastaustani vastaamaan, että olen lukenut paperin väärin tai muistan sen väärin. (En muista nyt, se oli aikoja sitten.)
#6
+2
martin
2011-06-12 20:11:15 UTC
view on stackexchange narkive permalink

Jos käytät "ohjelmisto" -avaimia (eli .ssh-hakemistoon tai vastaavaan tallennettuja avaimia), olet periaatteessa samalla tasolla kuin salasanoja.

OpenSSH: lla on nyt melkein kunnollinen PKCS # 11 -tuki, sama on saatavana KiTTY: ssä (PuTTY-haarukka), joten jos haluat todella käyttää pubkey-todennusta, valitse älykortti. Sitten on todellinen ero salasanoista. Salasanalla suojattu ohjelmiston avaintiedosto voidaan kopioida samalla tavalla kuin tavallinen salasana, kun taas älykortti ei.

Kuten muissa vastauksissa todetaan, on olemassa paljon skenaarioita, joissa pk auth on erittäin tehokas suoja, joten sinun tulisi ainakin selventää käsittelemiäsi uhkaskenaarioita.
Jos vastustaja vaarantaa isäntäsi (muu kuin kadonnut / varastettu, eli olet hakkeroitu / juurtunut / avainkoodattu jne.), Salasanalla suojatut yksityiset avaimesi ovat yhtä hyviä kuin yksinkertaiset tavalliset salasanat, jotka haetaan - molemmat voidaan kopioida ja käyttää ilman suostumuksesi. Älykortin kloonaus on toisaalta osoittautunut "tarpeeksi vaikeaksi" kaltaisille kuolevaisille. Älykortin tuhoaminen tavallisesti tuhoaa myös yksityisen avaimen. Tiedostokopion poistaminen ei tarkoita, että muita kopioita olisi "jonnekin"
Varma. Mutta ohitat suojauksen, jonka jopa ohjelmistopk-todennus antaa sinulle salasanan menettämiseltä etäkoneelle (mahdollista uudelleenkäyttöä muissa isännissä, joissa olet käyttänyt sitä uudelleen, kuten niin monet ihmiset tekevät) tai MITM: ään, kuten muut ovat huomauttaneet.
Voi olla. Mutta toivon, että olen kiinnittänyt huomion myös (vain salasanasuojatun) avainpohjaisen todennuksen ongelmiin.


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...