Onko turvallista säilyttää salasanoja palvelimella salattuina tekstitiedostossa?
Esim.
$1$qFy.dOkx$GJzGnGecR8JhRx8G.5d391
Onko seuraava tapa salasanan tarkistamiseksi turvallinen?
$annettuSalasana = "heikkosalasanani"; // tavallisesti: $_POST['salasana']; $oikeaSalasana = '$1$qFy.dOkx$GJzGnGecR8JhRx8G.5d391'; // noudetaan tavallisesti tekstitiedostosta if (crypt($annettuSalasana, $oikeaSalasana) == $oikeaSalasana) echo "Salasana oikein! :-)"; else echo "Salasana on virheellinen! :-(";
Täällä on hyvä koodivinkki salasanojen käsittelystä:
https://www.ohjelmointiputka.net/koodivinkit/
Eihän tuo vinkki edes vastaa kysymykseen, kun juuri luku- ja tallennusmetodit on jätetty toteuttamatta. Vastaus: ihan yksi ja sama, minne hashit tallentaa, kunhan ne ovat jossain minne ei pääse selaimella surffailemaan. Jos sellaista mahdollisuutta ei ole, niin sitten voi kokeilla rajoittaa päässyä htaccessilla tai muilla keinoin.
En ole tiennytkään, että täällä on tuollainen opas.
Näyttää hyvältä. Kiitos!
Lisäys:
The Alchemist kirjoitti:
Eihän tuo vinkki edes vastaa kysymykseen, kun juuri luku- ja tallennusmetodit on jätetty toteuttamatta. Vastaus: ihan yksi ja sama, minne hashit tallentaa, kunhan ne ovat jossain minne ei pääse selaimella surffailemaan. Jos sellaista mahdollisuutta ei ole, niin sitten voi kokeilla rajoittaa päässyä htaccessilla tai muilla keinoin.
Kyseiseen tiedostoon ei pääse käsiksi selaimella.
Tarkoitin lähinnä, luoko tuo crypt()-funktio tarpeeksi turvallisia tiivisteitä, jos vaikka joku jotenkin saisi tuon tiedoston haltuunsa.
Crypt() on kylläkin väärä funkkari salasanojen hashaamiseen. Php:hen on versiossa 5.5 lisätty nuo äsken esitellyn koodivinkin käsittelevat password-funktiot, jotka käyttävät crypt()-funkkaria pellin alla mutta paljon järkevämmillä oletusarvoilla.
Tavallisella crypt-funktiolla voi luoda sekä hyviä että huonoja tiivisteitä, sillä funktio hallitsee monia eri algoritmeja. Jos et ole todellinen guru tiivisteiden kanssa, käytä PHP:n varsinaisia salasanafunktioita, jotka esitellään koodivinkissä. Ne käyttävät tällä hetkellä oletuksena bcrypt-algoritmia kustannuksella 10 sekä satunnaista suolaa, ja jos tämä tulevaisuudessa käy liian helpoksi, PHP:n kehittäjät voivat vaihtaa kustannusta tai algoritmia ilman, että skriptejä tarvitsee muuttaa. Toki voit tehdä saman crypt-funktiolla (etuliite $2y$10$ ja sopiva suola), mutta onhan nyt tyhmää tehdä valmis asia uudestaan ja vielä tulevaisuudessa joutua korjailemaan itse koodia.
Tiedosto ja tietokanta ovat aivan yhtä turvallisia tallennuspaikkoja sikäli, että myös tietokannassa tieto tallennetaan kyllä levylle tiedostoihin – erityisessä muodossa vain. Pääasia on varmistaa, ettei ulkopuolinen voi lukea tietoa. Toisin sanoen kysymyksesi on sikäli epärelevantti, että jos joku joskus pääsee edes kokeilemaan tiivisteiden murtamista, tietoturvasi on jo epäonnistunut.
Metabolix, tuo selvensi paljon. Kiitos!
Se, että joku saisi tiedoston haltuunsa oli vain kuvitellinen tilanne, jonka en usko toteutuvan.
Tietenkin tavoiteeni on, että kukaan ei pääse käsiksi tietokannan (tai tietokantana käytettävien tekstitiedostojen) sisältöön. Haluan kuitenkin, että tiivisteet ovat vahvoja – ihan vain varmuuden vuoksi.
Väärin päin. Tiivisteiden pitää olla vahvoja, jotta salasanoja ei saa purettua auki, kun joku pääsee tietokantaan käsiksi. Tietokanta suojataan julkiselta pääsyltä ihan vain varmuuden vuoksi.
The Alchemist kirjoitti:
Väärin päin. Tiivisteiden pitää olla vahvoja, jotta salasanoja ei saa purettua auki, kun joku pääsee tietokantaan käsiksi. Tietokanta suojataan julkiselta pääsyltä ihan vain varmuuden vuoksi.
Eikös pääsy tietokantaan ole poikkeustilanne, jota ei pitäisi tapahtua? Tämän perusteella edellinen väite tuntuu hieman virheelliseltä. Käsittääkseni hyvin suojatussa tietokannassa salasanat voisivat olla aivan selkokielisenä. Salasanat suojataan tiivisteellä, jotta mahdollinen murto ei vaarantaisi käyttäjien salasanoja.
Salasanat eivät todellakaan voi olla koskaan selkokielisinä kannassa. Tietokantaan on aina rajaton pääsy jollain taholla - vähintään ylläpitäjillä. Jos vaikka luottokorttitietoja säilytettäisiin selkokielisinä tietokannassa, niin olisi hyvin suuri riski siihen, että firman työntekijät alkaisivat tehdä luottokorttipetoksia. Tai jos käyttää samaa salasana-käyttäjätunnusparia, niin olisi hyvin helppoa katsoa omasta kannasta tunnukset ja niitä käyttäen kirjautua muihinkin palveluihin.
Salasanojen kanssa asia menee ehdottomasti niin päin, että tiivistäminen on se tärkein tietoturvan pointti ja sen jälkeen vasta tulee tiivisteiden piilottaminen julkiselta pääsyltä.
Yleisesti ottaen tietysti tietokantaan pääsyn pitää olla yksityistä, koska kanta voi sisältää muitakin yksityisiksi tarkoitettuja tietoja, jotka ovat selkokielisessä muodossa. Kaikki tieto ei kuitenkaan ole niin arkaluontoista, että koko tietokanta pitäisi kryptata vain sen takia, että henkilökunta saattaisi lukea kyseisiä tietoja (tai että ne vuotavat ulos). Lisäksi yritykset voivat tietysti valvoa tietojen sisäistä käpistelyä omilla menetelmillään, mutta väärinkäytöksistä tuskin huudellaan asiakkaille.
"Hyvin suojattu tietokanta" on jonkinlainen kultaiseen yksisarviseen verrattavissa oleva myytti. Tietokanta on määritelmän mukaisesti avoin: suoritat kyselyn ja saat ulos tuloksen. Ainoa tapa rajoittaa tuloksia on kryptata arvot.
Salasanojen käsittely pienentää vahinkoa kun matsku joutuu kolmannen osapuolen käsiin. Joten tosiaan mielestäni ei kannata sanoa että salasanat käsitellään "varmuuden vuoksi", vaan ne käsitellään siksi että se pienentää vahinkoa.
Lähtökohtaisesti ottaen tietyt tahot toki pääsevät kantaan käsiksi, mutta he pääsevät yhtä lailla käsiksi lähettämääsi salasanaan (kun kirjaudut yms).
Joten joudut luottamaan siihen että käyttämäsi palvelu ei pelaa (tarkoituksella tai ilman) vilunkipeliä sille antamiesi tietojen suhteen.
Tässä jokaisen salasanoja käyttävän kannattaa muistaa käyttää kullekin palvelulle sellaista "salasanaa", mikä ei paljasta liikaa missään vaiheessa (kun salasana vuotaa - mahdollisesti oikein käsiteltynä - kannasta, tai kun salasana otetaan haltuun kirjauduttaessa).
Tällä koitan nostaa esille sitä tärkeintä seikkaa, eli oman salasanan valintaa.
Webbipalvelun tehtävä toki on käsitellä salasanat asianmukaisesti ja huolehtia että näihin salasanatiivisteisiin ei pääse ylimääräiset käsiksi. Mutta loppujen lopuksi voit ainoastaan itse vaikuttaa millainen haitta syntyy jos kyseinen salasanasi joutuu, muodossa tai toisessa, ulkopuolisten käsiin.
Eli HTML5:lle, käytä tosiaan yllä linkatussa koodivinkissä mainittuja funktioita, ja pidä huoli että systeemissäsi ei ole injektio-aukkoja yms. turvaongelmia, ja että hostaat palvelusi luotettavassa paikassa.
Teknisenä nyanssina, yleensä suositellaan että salasanan tiivistämiseen käytetty aika olisi maksimissan luokkaa "alle 100ms", joten testaa toimiiko password_hash() oletuksena palvelimellasi näin. Varmaankin hyvä geneerinen sääntö on että tähtää lähelle 100ms.
Tuo ylläoleva kappale sillä olettamuksella että käsittelet interaktiivisia kirjautumisia palvelimen päässä.
Jos kantaan kerran on rajaton pääsy, niin kyllä se minusta on aika kummallinen järjestelmä. Tietokantaan ei kaiketi pitäisi päästä tekemään kyselyitä kovinkaan vapaasti. En tiedä miten sinulla nuo tietokantaoperaatiot suoritetaan, mutta minusta käyttäjän ei pitäisi päästä kirjoittamaan kyselyitä kannalle.
Minusta salasanoja tai niiden tiivisteitä ei pitäisi joutua käyttäjien käsiin. Tältä osin uskon, että olemme samaa mieltä. Kryptaaminen ei tuloksia juuri rajoita - niiden käyttöä ehkä hiukan. Toki kannasta saadaan haettua dataa taustajärjestelmän mahdollistamilla tavoilla, mutta näillä menetelmillä (muiden) käyttäjien salasanoja tai niiden tiivisteitä ei saisi kulkeutua käyttäjän näkyville.
The Alchemist tarkoitti, että esimerkiksi sivuston ylläpitäjällä on kantaan rajaton pääsy. Minusta tuollaiseen vainoharhaisuuteen ei kannata ryhtyä.
Toki tieto on hyvä tallentaa turvallisessa muodossa, mutta tiivistefunktiot eivät ole siihen universaali ratkaisu: niillä voi suojata vain salasanoja, joita ei tarvitse koskaan saada tietokannasta takaisin selväkieliseen muotoon. Jotta tietoja pystyttäisiin myös lukemaan, on pakko joko luottaa ylläpitäjiin ja työntekijöihin tai kehittää toinen toistaan hienompia ratkaisuja datan purkamiseen käyttäjän henkilökohtaisella avaimella käyttäjän omalla koneella. Esimerkiksi terveydenhuollossa jälkimmäistä mahdollisuutta ei edes ole, koska tietoja pitää pystyä käyttämään myös henkilön itsensä ollessa estynyt.
Jos salasanan murtamisesta on edes vähän vaivaa, on luultavasti tehokkaampaa vain alkaa vakoilla käyttäjien kirjautumisia ja poimia salasanat suoraan selväkielisinä. Hetkellisten houkutusten torjumisessa siis riittää, ettei salasana ole ihan suoraan luettavissa; tahallisilta väärinkäytöksiltä ylläpitäjiä ei estä oikein mikään.
Aihe on jo aika vanha, joten et voi enää vastata siihen.