Kysymys:
Eikö OAuth, OpenID, Facebook Connect ja muut ole hulluja turvallisuuden näkökulmasta?
Oscar Godson
2011-05-22 11:18:41 UTC
view on stackexchange narkive permalink

Työskentelen jatkuvasti sovellusliittymien kanssa ja työskentelen web-kehittäjien kanssa, jotka vaativat, että OAuth, OpenID jne. ovat paljon parempia kuin koti-panimo-menetelmä. Jokainen sivusto näyttää käyttävän näitä myös nyt käyttäjän helppokäyttöisyyden lisäksi myös turvallisuuden vuoksi. Kuulen sen joka päivä melkein siitä, että se on turvallisempi, mutta minusta on erittäin vaikeaa uskoa muutamista syistä:

  1. Jos hakkeri jotenkin saa salasanasi yhdelle sivustolle, hän tietää hänellä on pääsy suurimpaan osaan sivustoista, joissa vierailet nyt.

  2. Se tekee tietojenkalastelusta 10 kertaa helpompaa. Kun niin monet ihmiset käyttävät samoja kirjautumistunnuksia ja tekevät sen uudestaan, ihmiset eivät todennäköisesti todennäköisesti lue kaikkea ja tarkista URL-osoite ylhäältä.

Voisitko luetella lisää syitä, miksi se on vaarallista, vai voisitko selittää minulle, miksi se on turvallisempaa? En ymmärrä, miksi sietäisit vaivaa integroida yksi näistä, kun näyttää siltä, ​​että käyttäjän olisi hyvä kirjoittaa 3 kenttää (käyttäjänimi, salasana, sähköposti) sen sijaan, että napsautaisit palvelun logoa kirjautumiseen (Twitter, Google, FB jne.), Kirjoittamalla käyttäjätunnuksensa / salasanansa, napsauttamalla Lähetä, napsauttamalla Hyväksy.

== Update ==

Laajenna kysymystäni pyynnön mukaan.

Edellä olevaan kahteen kohtaan, # 1 , ei ole väliä kuinka hakkeri saa sen. En ole varma, kuinka laajentaa sitä tarkalleen. Voisit raa'asti pakottaa sen, arvailla sen, käyttää unohdettua salasanaa ja tehdä sanastohyökkäys yleisiin kysymyksiin jne. Mutta kuitenkin, teet sen mielestäni Yksi salasana 1000 palvelimen käyttämiseen on paljon vähemmän turvallinen kuin 1000 salasanaa pääsy 1000 eri sivustoon. Voin henkilökohtaisesti arvata, että muutamilla ystävieni ja perheeni salasanoilla ja huonoin pääsy kaikenlaisiin tileihin. Minun ei tarvitse edes etsiä niitä. Kun selaan Internetiä sairaana, kirjaudu vain sisään ... Jos olin hakkeri, monet näistä salasanoista on erittäin helppo murtaa. Jotkut ystäväni salasanoista ovat pepsi , tina (sitten syntymävuosi), 123456 ja muut tyhmät. Suosikkini on kuitenkin tomcruisesucks LOL.

# 2 -kohdan laajentamiseksi edelleen saatan mennä osoitteeseen http: // wired. fi, http://klout.com, http://twitter.com, http://thenextweb.com ja heillä kaikilla on Twitter-kirjautumistunnus. Luotan sivustoihin (suurimmaksi osaksi), joten rehellisesti sanottuna en tarkista sisäänkirjautuvan ponnahdusikkunan URL-osoitetta ja oletan, että useimmat eivät. Tuon ponnahdusikkunan olisi voinut helposti hakata hakkeri, joka pääsi johonkin palvelimestaan, tai paha työntekijä, tai vain väärennetty sovellussivusto, jonka botti lähettää ihmisille twitterin kautta, että useat ihmiset kirjautuvat sitten tähän väärennettyyn sovellukseen, mutta käyttävät Twitter-kirjautumistunnus.

Ihmiset ovat tottuneet näkemään samat kirjautumissivut, jotka eivät enää näy . Jos tämä ketju tulee tarpeeksi suosituksi, voin helposti tehdä erittäin yksinkertaisen testin Twitterissä tai FB: ssä lähettämällä kaikille linkin väärennettyyn sovellukseen, minulla on ponnahdusikkuna, joka näyttää Twitteriltä tai FB: ltä ja he kirjautuvat sisään. Takaan sen. Jos panen kirjautumisnäytön siirtymään, sanotaan, http://bankofamerica.com tai http://paypal.com, he kysyvät itseltään, miksi olen täällä , miksi he tarvitsevat tätä tietoa jne. Samat sivustot, joita käytettiin kirjautumiseen uudestaan ​​ja uudestaan, on käytännössä erittäin huono.

Se on minun laajennettu keskustelupiste;)

Oletko haistanut eri todennustavat? Miltä se näyttää langalta? Tunnemmeko protokollan? Mikä menee palvelimelle ja palvelimelta, eräänlainen asia.
@marcin - openid ja oauth ovat hyvin avoimia ja suhteellisen hyvin tarkastettuja standardeja, joissa on tekniset tiedot, wikipedia-sivut jne. YMMV Facebook Connectin kanssa ....
Tähän kysymykseen on vaikea vastata, koska siinä on paljon erilaisia ​​näkökohtia. Ensinnäkin, et selvitä tarkalleen mitä vaihtoehtoa olet mielessäsi oautille. Mikä on sovelluksemme? Toiseksi, facebook connect on oletettavasti oma, ja siten hyvin erilaisessa liigassa kuin oauth ja openid. Ja kolmanneksi, kommenttisi tietojenkalastelukysymyksistä ihmisten Facebook-seinillä olevien linkkien käytöstä on aivan eri aihe. Ehdotan, että muokkaat facebook connect- ja facebook link -osat täältä ja esität erillisiä kysymyksiä niistä, jos haluat.
@nealmcb Miksi et käyttäisi homebrew-menetelmää tai yksinkertaisesti etsiä evästeitä. I.E. Käyttäjä kirjautuu palveluun ja hänellä on sitten API-käyttöoikeus. tämä voidaan helposti tehdä iframe- tai POST-lomakkeella. Kaikilla palveluilla riippumatta siitä, ovatko avoimen lähdekoodin vai eivät, ole samat puutteet ja mitä minä sanon. ne kaikki yhdistävät kaikki tilisi yhdellä salasanalla. Jälleen, 3. pisteesi, se on _täsmälleen_ sama Ouathille tai oikeastaan ​​KAIKKIEN sivustoille, mutta se on pahempaa, kun suurilla sivustoilla on salasanasi, koska ihmiset eivät tarkista URL-osoitetta. Luulen, että sinulta puuttuu 2 numeroitua pistettäni ...
Useimmat ihmiset eivät lue kommentteja, joten on hyödyllistä, jos pystyt muokkaamaan kysymykseen tietyssä hyökkäysskenaariossa. Mitä omaisuutta suojaat, millaisilta uhilta jne. Katso FAQ Sitten voimme keskustella siitä vastauksissa.
Tehty! Olen laajentanut kahta kohtaa
Kiitos. Minun on sanottava, että on edelleen epäselvää, mikä kysymyksesi on - mitä ongelmaa yrität ratkaista, mistä näkökulmasta. Päätätkö, käytetäänkö näitä tekniikoita omassa sovelluksessasi? Käytetäänkö openidia vai mukautettua kirjautumista tietylle sivustolle? Voimmeko odottaa sopivan, mikä vastaus on oikea? Meidän pitäisi pystyä - katso usein kysytyt kysymykset ja huomaa, että tämä sivusto ei ole tarkoitettu "keskusteluihin".
Olen pitkäaikainen (melkein 2 vuotta) StackOverflow-käyttäjä, tiedän säännöt :) ja kyllä, oikea vastaus on. Lyhyesti, yhden lauseen kysymys: Ovatko nämä todennustavat todella turvallisempia kuin oma kirjautumisjärjestelmä. Muut alla olevat ihmiset näyttävät ymmärtävän, joten en ole varma, kuinka laajentaa: \ "Oikea" vastaus on selitys joko kyllä ​​sen turvallisemmalle ja miksi tai ei vastaukselle ja miksi pidän / ymmärrän / kaikkein yksityiskohtaisimmasta vastauksesta.
Google tukee u2f: tä, mikä tekee tietokalastelusta 1000x vaikeampaa.
Kymmenen vastused:
#1
+23
Hendrik Brummermann
2011-05-22 13:59:10 UTC
view on stackexchange narkive permalink

Luulen, että jokapäiväisille verkkosivustoille ei ole oikeastaan ​​hyvää ratkaisua (esim. ei korkean profiilin sivustoja, kuten pankkeja, joiden käyttäjät hyväksyvät ja taloudellinen sallii kahden tekijän todennuksen). Voidaan valita vain ratkaisu, jolla on mahdollisimman vähän kielteisiä vaikutuksia.

Valitettavasti ihmiset eivät osaa muistaa valtavaa määrää salasanoja. Tämän seurauksena joko ne käyttävät samaa salasanaa uudelleen eri palveluissa tai kirjoittavat ne muistiin (paperille tai salasananhallinnalle). Kyllä, on neuvoja luoda salasanajärjestelmä, joka sisältää sivuston nimen.

Mutta ihmiset ovat laiskoja. Salasanan uudelleenkäyttö on huonompi kuin keskitili, koska se tarkoittaa, että minkä tahansa sovelluksen haavoittuvuus paljastaa salasanan.

Stendhal -pelissä suurimman osan tilin hakkeroista tekevät perheenjäsenet. Luulen, että se on erityistä peleille. Seuraava ryhmä on käyttäjänimien / salasanojen arvaaminen. Mutta on olemassa pieni määrä hakkerointiyrityksiä, jotka perustuvat pääsyyn sähköpostitiliin . Vaikka emme salli automaattista salasanan palauttamista sähköpostilla, monet sivustot tekevät. Twitterin ylempi johto hakkeroitiin hyödyntämällä vanhentunutta Hotmail-sähköpostitiliä ja uudelleenkäytettyjä salasanoja.

Joten jos harkitset salasanan palauttamista sähköpostitse, todennusprosessin siirtämisessä on vähän lisäriskiä. suurille yrityksille. Kaikilla heillä on käytössään keino vaikeuttaa hyökkääjiä (palautuminen matkapuhelinviesteillä epäilyttävän toiminnan sattuessa, sisäänkirjautumishistoria, varoitukset sisäänkirjautumisyrityksistä muissa läänissä jne.). Omien sivustojesi käyttöönotto on paljon työtä.

Henkilökohtaisesti olisin halunnut tilivastaava -tavan ( määrittely). ) yli luottamuksen johonkin näistä yrityksistä. Lisäksi sillä ei ole phishing-ongelmaa. Valitettavasti projekti ei näytä edistyvän.

Lopulta päätimme, että Stendhal tukee sekä OpenID- että paikallisia tilejä ja antaa käyttäjien päättää.

Googlella on kaksivaiheinen todennus.
#2
+17
Rory Alsop
2011-05-22 13:46:39 UTC
view on stackexchange narkive permalink

Turvallisuuden näkökulmasta kokeiltu mekanismi on melkein aina parempi kuin oman liikkuminen. Toteutusvirheet ovat yksi yleisimmistä tavoista, joilla hyvä tietoturvakonsepti hajoaa.

Käytettävyyden näkökulmasta pidän hieman parempana oauthista, sitä on vain helppo käyttää, joten loppukäyttäjillesi tämä on valtava etu. Keskimääräinen ei-tekninen käyttäjä lannistaa avointa tietoturvaa, joten tietoturvaominaisuuksien tunkeutumisen minimointi on voitto sivustoille, joilla on paljon käyttäjiä.

Tietojenkalasteluriski ei todellakaan ole suurempi - ihmiset eivät älä kiinnitä mitään huomiota sähköpostilähteeseen joka tapauksessa :-)

Se pitää paikkansa sähköpostin tietojenkalastelusta lukuun ottamatta sitä, että useimmat sähköpostipalvelujen tarjoajat (Yahoo, Live, Gmail jne.) Eivät anna tietojenkalastelusivustojen päästä läpi. Huoleni on enemmän kuin ystäviesi FB: n tai Twitterin linkit, jotka sanovat "tarkista tämä linkki"
#3
+17
user185
2011-05-22 13:58:12 UTC
view on stackexchange narkive permalink

OAuthin kaltaisten järjestelmien edut ovat:

  • maailmassa on vähemmän tietokantoja, jotka tallentavat käyttäjän kirjautumistiedot. Kun otetaan huomioon Twitterin kaltainen palvelu, tämä tarkoittaa, että käyttäjänimesi ja salasanasi tiedetään vain Twitterille, ei Favstarille, Amazonille, LinkedInille, New York Timesille ja kaikille muille sovelluksille, jotka rakentuvat palvelun päälle.
  • Kuten @Rory sanoo, järjestelmä on laajalti käytössä, ja se on testattu ja (toivottavasti) varmistettu asianmukaisella tavalla.

Molemmat edut koskevat kohtaasi 1: OK, joten kaikki nämä palvelut käyttävät samaa salasanaa, mutta niiden on joka tapauksessa käytettävä, koska heidän kaikkien on käytettävä Twitter-tiliäsi, joten on parasta varmistaa, että näitä "yleisiä" tunnistetietoja ei tallenneta moniin paikkoihin erilaisilla suojaustoimenpiteillä.

Perushaitta ei eroa haittapuolista, joka vaikuttaa kaikkiin kirjautumiskäyttöliittymiin: kuka tahansa voi tehdä sellaiseksi näyttävän kirjautumiskäyttöliittymän ja käyttää sitä tunnisteiden hankkimiseen.

** 1. ** kohta on totta, jos käytät samaa tarkkaa salasanaa ja käyttäjänimeä, mutta eri salasanat 1000 eri palvelimella on turvallisempaa kuin 1 salasana 1000 palvelimella, eikö? ** 2. ** Kyllä, kuka tahansa voi kirjautua sisään, mutta FB-kirjautumissivun / -näppäimen näkeminen puoli tusinaa kertaa päivässä satunnaisen sivuston kertaluonteiseen sisäänkirjautumiseen on valtava ero. Jos olin sivustolla site1.com ja sillä oli kirjautumissivu sivustolle site2.com, se olisi outoa. Jos site1.comilla olisi kirjautumissivu facebookiin, useimmat käyttäjät eivät edes ajattele sitä. Sitä mitä minä tarkoitan.
@Oscar: tilanteissa, joissa OAuth on hyödyllinen, sinulla ei voi olla 1000 erilaista salasanaa. "joten kaikki nämä palvelut käyttävät samaa salasanaa, mutta niiden on joka tapauksessa oltava, koska heidän kaikkien on käytettävä Twitter-tiliäsi"
@Oscar valitettavasti useimmilla ihmisillä on täsmälleen sama salasana / käyttäjätunnus mutipul-sivustoille, koska heidän laiskansa ja / tai välittämättömyytensä ja / tai uusien salasanojen myöhäisen ajattelun / muistamisen aiheuttama kipu / unohtaminen ja unohtaminen salasanan vaihtaminen on suurempi kuin Malloryn pääsy heidän tiliisi.
#4
+16
nealmcb
2011-05-25 02:54:44 UTC
view on stackexchange narkive permalink

Ilman tiettyä skenaariota ja uhkamallia on vaikea vastata kysymykseesi.

Mutta yksi selvä voitto on klassinen OAuth-käyttötapaus. On käynyt ilmi, että käyttäjät ovat hämmästyttävän halukkaita antamaan yhdelle verkkosivustolle salasanansa toiselle verkkosivustolle, esim. Google-salasanansa sosiaaliseen verkostoitumiseen, kuten Shelfari. Ja kuten Kalsey toteaa, he olivat joskus kamalasti yllättyneitä siitä, mitä Shelfari teki tällä salasanalla, ja koska Shelfari pystyi täysin esiintymään heinä, Google ei voinut helposti lopettaa väärinkäyttöä.

Nyt OAuth-sovelluksen, kuten sovelluksen, kanssa Shelfari saisi vain osittaisen pääsyn API: n kautta käyttäjän yhteystietokantaan, ja Shelfari käyttäisi API-avainta, jonka Google voisi helposti peruuttaa.

Käyttäjät käyttävät todellisessa maailmassa todennäköisesti salasanoja uudelleen useilla sivustoilla. , joten hyökkäykselläsi # 1 on mahdollisuus työskennellä monissa paikoissa sellaisenaan. Itse asiassa voimme toivoa, että käyttäjät käyttävät parempaa salasanaa tärkeälle OpenID-sivustolleen tai käyttävät 2-tekijäistä todennusta tai mitä tahansa muuta.

Mitä tulee # 2: een, OpenID-kirjautumisella on se, että siitä tulee epätavallista. juosta sivuston yli, jonka mielestä et ole kirjautunut sisään, kun huomaat, että olet kirjautunut sisään muilla verkkosivustoillasi. Toisaalta on jo helppoa ilman OpenID: tä tai OAuthia tehdä sivustosta Twitter-linkki ja linkittää sivustoon ja toivoa vakuuttavan ihmiset kirjautumaan sisään ja nappaamaan salasanansa. Jos ihmiset ovat aina kirjautuneet Twitteriin (esim. Muille sivustoille OAuthin tai OpenID: n kautta), he todennäköisesti kysyvät, miksi he eivät ole jo kirjautuneet sisään.

#5
+11
Rakkhi
2011-05-23 14:19:50 UTC
view on stackexchange narkive permalink

Kirjoitti tämän liittotunnuksesta.

Pohjimmiltaan puhut keskitetystä riskiongelmasta tai valtakunnan avaimista. Tämä koskee myös salasananhallitsijoita, mutta pienen määrän henkilöllisyys- ja todennusjärjestelmien suojaaminen on paljon helpompaa ja tehokkaampaa kuin satojen heikkojen salasanojen (tai saman heikon salasanan sata kertaa) saaminen. Googlen kaltaiset avoimen tunnuksen tarjoajat tarjoavat nyt kaksivaiheisen todennuksen; Jos et pidä puhelimesi pehmeästä tunnuksesta, monet Open-ID-tarjoajat tukevat myös Yubikey USB -laitemerkkejä. Myös valvontaa ja tilintarkastusta parannetaan huomattavasti; tunnetko jokaisen sovelluksen, jossa olet käyttänyt salasanaa? En minäkään. Silti monilla Open-ID-palveluntarjoajilla on kaikki sivustot, joille olet myöntänyt pääsyn kyseiseen henkilöllisyyteen, käyttöoikeuden peruuttaminen on yhden napsautuksen prosessi. , analytiikka ja lisääntyneet mahdollisuudet tarttua virukseen. Lisää, että se on nopeampi ja halvempi kuin maksaa ohjelmoijalle kehittää todennustoiminto jonkinlaisen yhdistetyn todennuksen avulla, minusta ei ole järkevää.

#6
+10
Kim
2011-05-22 11:53:54 UTC
view on stackexchange narkive permalink

Käytän Googlea OpenID-tililläni. Lähes kaikki verkkosivustot, jotka eivät käytä OpenID: tä, antoivat minun nollata salasanan sähköpostitse, joten jos joku saisi salasanan gmail-tililleni, minua ruuvittaisiin joka tapauksessa.

Tämä on totta, mutta Google on vaikeampi hakata, ja ne estävät raakaa voimaa ja muuta. Luotan Googleen paljon enemmän, sanotaan sitten Klout.com tai jotain. Mutta joo, saan mitä sanot :)
#7
+7
Lie Ryan
2011-06-23 09:33:20 UTC
view on stackexchange narkive permalink

1 salasanan tallentaminen 1000 palvelimeen on vähemmän turvallista kuin 1 salasanan tallentaminen yhdelle palvelimelle, joka todentaa 999 palvelinta on vähemmän turvallinen kuin 1000 salasana 1000 palvelimelle .

Jälkimmäinen on kuitenkin epäkäytännöllinen, ihmiset eivät kykene muistamaan 1000 salasanaa 1000 palvelimelle, ainoa tapa tehdä se on käyttää salasanojen hallintaohjelmia. Ja missä salasananhallinta on?

1-salasanan tallentaminen yksisuuntaisella salauksella 1000 palvelimelle on vähemmän turvallista kuin 1-salasana salasananhallinnalle, joka tallentaa 1000 salasanat selkeässä tekstissä tai kaksisuuntaisessa salauksessa 1000 palvelimelle on vähemmän turvallinen kuin 1 salasana, joka on tallennettu yksisuuntaiseen salaukseen yhteen palvelimeen, joka todentaa 999 palvelinta on vähemmän turvallinen kuin 1000 salasana tallennettu yksisuuntaisella salauksella 1000 palvelimelle .

Siksi OAuth / OpenID voi olla turvallisempi, kätevämpi ja käytännöllisempi. 1000 salasanan käyttäminen ilman salasananhallintaa on epäkäytännöllistä ja salasanan hallinnan käyttö on vähemmän turvallista, koska nämä salasanat on tallennettava pelkkänä tekstinä tai kaksisuuntaisena salauksena.

Hyväksy, "1000 salasana 1000 palvelimelle" on ihanteellinen maailma;se on yleensä "1 salasana tallennettu 1000 palvelimeen".Jos salasana vaarantuu, sinun on vaihdettava salasana 1000 palvelimessa (ja muista, että sinulla on tili siellä).
#8
+5
Lie Ryan
2012-09-22 02:30:25 UTC
view on stackexchange narkive permalink

Yksi tapa, jolla OAuth ja OpenID parantavat tietoturvaa, on se, että sinun on kirjoitettava salasanasi harvemmin. Uuden tilin linkittäminen OAuth / OpenID: hen vain ohjataan minut identiteettipalveluun, ja koska olen jo kirjautunut sisään identiteettipalveluun jatkuvasti, se antaa yksinkertaisesti Kyllä / Ei -kehotteen salasanakehotteen sijaan. Mikään salasana ei kulje koko vaihdon ajan.

Tämä tekee sinusta itsetietoisemman, jos sinulta todella kysytään salasanaa vain kulkemisen sijaan.

Joten # 2 ei todellakaan ole ongelma.

#9
+4
pepe
2011-06-23 07:40:15 UTC
view on stackexchange narkive permalink

# 2 on ehdottomasti totta, mutta ei ensisijaisesti liittovaltion tunnuksen ongelma, vain että se on vielä kriittisempi tässä tapauksessa.

Sinulla on samanlaisia ​​ongelmia kaikkien kirjautumislomakkeiden kanssa upotettu (oikeastaan) epäluotettavaan sisältöön, varsinkin kun käytetty todennus on epävarminta (salaisuus välitetään yksinkertaisesti selaimella, ja jos olet onnekas, palvelin laittaa SSL: n sinun mukavuutesi vuoksi ..).

Tämän ja useimpien muiden tietojenkalasteluhyökkäysten korjaamiseen tarvitaan kaksi asiaa:

  • suojattu käyttöliittymä käyttäjän todennukseen, esim. pudotusvalintaikkuna URL-osoitepalkista, EI EI osa palvelimen sisältöä.

  • natiivisti toteutettu todennusprotokolla (ei palvelinsisällön, kuten JavaScriptin mukaan), joka ei paljasta salaa mahdollisesti haitalliselle palvelin (esim. SRP)

BTW, toteutin SRP: n NSS: lle useita vuosia sitten ja toiset jopa GUI-laajennuksia. Ellei älykortista tule kaikkialla, tämä on oikea tapa: http://trustedhttp.org/wiki/TLS-SRP_in_NSS

#10
  0
Vicky
2016-05-26 19:58:24 UTC
view on stackexchange narkive permalink

Ihmiset haluavat aina siirtää vastuunsa harteiltaan (eivät kaikki). Turvallisuus on suuri vastuu, ja suurin osa yrityksistä haluaa keskittyä ydinliiketoimintaan ja antaa asiakkailleen tuotteitaan parhaiten sen sijaan, että huolehtisi turvallisuudesta.

Yksi epäonnistumispiste on tietysti huolestuttava turvallisuusnäkökulmasta, mutta ihmiset haluavat luottaa suuriin yrityksiin, koska he saivat valtavia rahaa ja rahan mukana tulee hyviä turvallisuusinsinöörejä (ei tarkalleen, mutta joo! ). Hyvät insinöörit tarkoittavat hyviä turvallisuuskäytäntöjä. Lisäksi he eivät aio osoittaa selkäänsä ihmisille (toivottavasti!).

Tietojenkalastelu on ehdottomasti valtava ongelma, ja turvallisuusyhteisö on työskennellyt tämän asian parissa jo jonkin aikaa. Kuten @Rakkhi mainitsi, viimeisimmät ratkaisut, kuten Yubikey, Fido U2F ja tietojenkalastelukysymysten ratkaisemiseksi, voivat auttaa parantamaan tietoturvaa.

Ainoa asia, jonka voimme toivoa, on uusi suunnittelumuutos, jossa ihmisten ei tarvitse valita heidän salasanansa ja kirjoita ne samalla, kun pystyt todentamaan ne turvallisesti.



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