Joskus kauan sitten löysin tämmösen kirjautumiskoodin ja sitä käyttänyt omissa rojekteissa jotka ei mitään hirveetä tietoturvaa tartte mutta onko tämä nykyaikana miten turvallinen käyttää ja voiko sen turvallisuutta parantaa merkittävästi jotenkin helposti?
sivujen alussa:
<?php session_start(); include("ylaosa.php"); ?>
ylaosa.php
<?php ini_set('default_charset', 'iso-8859-1'); error_reporting(0); if(!isset($_SESSION)) { session_start(); } include("config.php"); //avataan yhteys tietokantaan $lnk = mysql_connect($db_server,$db_user,$db_passwd) or die ("Yhteys tietokantaan epäonnistui"); mysql_select_db($db_db,$lnk) or die ("Tietokannan valitseminen epäonnistui"); //käyttäjä on oletuksena false $user = false; /* SISÄÄNKIRJAUTUMINEN */ if(isset($_POST['tunnus']) && isset($_POST['salasana'])){ //muuttujat talteen $tunnus = get_magic_quotes_gpc() ? $_POST['tunnus'] : mysql_real_escape_string($_POST['tunnus']); $salasana = get_magic_quotes_gpc() ? $_POST['salasana'] : mysql_real_escape_string($_POST['salasana']); $salasana = md5($salasana); //luodaan käyttäjäkohtainen uniikki id $istuntotunnus = md5(uniqid("")); //lisätään istunto tietokantaan käyttäjän tietoihin mysql_query("UPDATE {$tbl_users} SET istunto = '{$istuntotunnus}' WHERE tunnus = '{$tunnus}' AND salasana = '{$salasana}'",$lnk) or die (mysql_error()); //jos lisättyjä rivejä on yksi, kirjautuminen onnistui if(mysql_affected_rows($lnk) == 1){ //laitetaan sessioon talteen istuntotunnus $_SESSION['log_key'] = $istuntotunnus; //takaisn edelliselle sivulle. Parempiakin tapoja on header("Location: ".isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : "etusivu.php"); } } if(isset($_GET['tunnus']) && isset($_GET['salasana'])){ //muuttujat turvallisesti talteen $tunnus = get_magic_quotes_gpc() ? $_GET['tunnus'] : mysql_real_escape_string($_GET['tunnus']); $salasana = get_magic_quotes_gpc() ? $_GET['salasana'] : mysql_real_escape_string($_GET['salasana']); $salasana = md5($salasana); //luodaan käyttäjäkohtainen uniikki id $istuntotunnus = md5(uniqid("")); //lisätään istunto tietokantaan käyttäjän tietoihin mysql_query("UPDATE {$tbl_users} SET istunto = '{$istuntotunnus}' WHERE tunnus = '{$tunnus}' AND salasana = '{$salasana}'",$lnk) or die (mysql_error()); //jos lisättyjä rivejä on yksi, kirjautuminen onnistui if(mysql_affected_rows($lnk) == 1){ //laitetaan sessioon talteen istuntotunnus $_SESSION['log_key'] = $istuntotunnus; //takaisn edelliselle sivulle. Parempiakin tapoja on header("Location: ".isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : "etusivu.php"); } } /* ULOSKIRJAUTUMINEN */ if(isset($_REQUEST['logout'])){ unset($_SESSION['log_key']); session_destroy(); header("Location: lockscreen.php"); } /* KÄYTTÄJÄN TUNNISTUS */ if(isset($_SESSION['log_key'])){ //HAETAAN KÄYTTÄJÄN TIEDOT $sql = "SELECT id, tunnus, istunto, salasana, email DATE_FORMAT(last_load,'%d.%m.%y %h:%i:%s') AS last_load FROM {$tbl_users} WHERE istunto = '".mysql_real_escape_string($_SESSION['log_key'])."'"; $sql = mysql_query($sql,$lnk); if($sql && mysql_num_rows($sql) == 1){ //käyttäjä tunnistettu, kaikki kunnossa $user = mysql_fetch_assoc($sql); //nyt käyttäjän tiedot ovat mukavasti $user[]-taulukossa //esim. käyttäjän id löytyy $user['id'] ja tunnus $user['tunnus'] //lisätään vielä käyttäjän viimeisestä sivunlatauksesta aikaleima mysql_query("UPDATE {$tbl_users} SET last_load = NOW() WHERE id = ".$user['id'], $lnk); } } echo '<?xml version="1.0" encoding="iso-8859-1"?>'; ?>
Nyt kun palvelin vaihtui nebulaan niin tuli ongelmaksi se että tuo katkasee session jostain syystä jo parin minuutin jälkeen. Ja ongelma on vain firefoxilla, ei esim. edgellä.. php.ini pystyy laittamaan time outit erikseen mutten oo koskenu siihen kun kummastelen sitä miksi firefox katkoo tuota niin aikaseen mutta muut ei?
Ja onko toi miten fiksu käyttäjän hallinta turvallisuuden osalta? Muutoni täyttää kyllä kaikki sen mitä tartten mainiosti.
Ainoa varsinainen turvallisuuspuute minkä huomasin on, että salasana tiivistetään MD5:llä ilman suolaa. Käyttäisin itse esim. BCryptiä, mutta jos MD5:ttä käyttää niin edes se suola mukaan sinne.
Muita huomioita:
Lähinnä tuossa pistää silmään tuo turha istuntotunnuksen kanssa pulailu. Ilmeisesti tarkoitus on että samalla tunnuksella voi olla vain yhdeltä koneelta yhteys, mutta md5 -tiivisteen laskeminen siitä on aivan turhaa.
Periaatteessa en myöskään pidä tuosta että muuttujan merkitys ($salasana) vaihtuu kesken - ensin se on selväkielinen salasana ja sitten salasanan tiiviste. Lisäksi mysql eskapointi ajetaan väärässä kohti. Tosin md5 -tiiviste nyt sitä ei välttämättä tarvitsisikaan, mutta niin ajateltuna eskapointi ajetaan turhaan.
Sitten tietty nykyaikana varmaankin käytetätisiin esim. PDO:ta ja parametrisoituja kyselyitä, eikä myöskään noille get_magic_quotes_gpc jutuille onneksi nykyään ole tarvetta.
Onko tuohon jotain selkokielistä opasta miten nuo kyselyt ja muut epäkohdat kannattaisi tänäpäivänä tehdä?
Muutoinhan tuo ei ole edes minun tekemä koodi vaan joskus löydetty täältä tai kuhan puolelta kaaaaaaaaaauan sitten... Mutta monta systeemiä sillä on tullu tehtyä, ainakin toistaiseksi toiminut mutta eipä sitä koskaan tiedä kuka innostuu sivuja hakkeroimaan.
Ite mysql kyselyt teen tämmöisellä, vähintään yhtä vanhalla tyylillä:
<?php include ('mysql.php'); $yhteys = mysql_connect($palvelin,$tunnus,$salasana) or die(mysql_error()); mysql_select_db($tietokanta,$yhteys) or die ("Tietokannan valitseminen epäonnistui"); $kysely = " SELECT tuotteet.ID, tuotteet.koodi, tuotteet.nimi, tuotteet.alv, tuotteet.hinta, varasto_tuote.varasto_id, varasto_tuote.tuote_id, varasto_tuote.kpl, varasto_tuote.alaraja, varasto_tuote.tavoite FROM tuotteet LEFT JOIN varasto_tuote ON varasto_tuote.tuote_id=tuotteet.koodi WHERE varasto_tuote.varasto_id='".$user['varasto_id']."' ORDER BY tuotteet.koodi ASC "; //suoritetaan kysely $haku = mysql_query($kysely, $yhteys) or die(mysql_error()); for ($i = 0; $i < mysql_num_rows($haku); $i++) { $varasto_ID = mysql_result($haku, $i, "varasto_tuote.varasto_id"); $paikkakunta = mysql_result($haku, $i, "varastot.paikkakunta"); $tuote_id = mysql_result($haku, $i, "tuotteet.ID"); $kpl = mysql_result($haku, $i, "varasto_tuote.kpl"); $alaraja = mysql_result($haku, $i, "varasto_tuote.alaraja"); $tavoite = mysql_result($haku, $i, "varasto_tuote.tavoite"); $koodi = mysql_result($haku, $i, "tuotteet.koodi"); $nimi = mysql_result($haku, $i, "tuotteet.nimi"); $alv = mysql_result($haku, $i, "tuotteet.alv"); $hinta = mysql_result($haku, $i, "tuotteet.hinta"); //juttuja... } ?>
tuo mysql.php tiedosto pitäisi tietenkin jotenkin suojata kun siellä on sisällä vain kaikki tunnukset muuttujissaan. Mikä olis fiksu tapa sen suojaamiseen?
sprawl kirjoitti:
Onko tuohon jotain selkokielistä opasta miten nuo kyselyt ja muut epäkohdat kannattaisi tänäpäivänä tehdä?
On montakin opasta, mm. MySQL-opas – PHP ja PDO, koodivinkki PDO:sta ja koodivinkki PHP:n salasanafunktioista.
sprawl kirjoitti:
tuo mysql.php tiedosto pitäisi tietenkin jotenkin suojata kun siellä on sisällä vain kaikki tunnukset muuttujissaan. Mikä olis fiksu tapa sen suojaamiseen?
En nyt tiedä, mitä tarkoitat suojaamisella. Eihän sivuston kävijä näe PHP-lähdekoodeja, paitsi jos palvelimen asetukset ovat väärät. Siinä mielessä siis ei ole tarvetta ”suojata” tiedostoa. Varmuuden vuoksi kuitenkin tiedoston voi sijoittaa sivuston ulkopuolelle eli ylempään hakemistoon. Jos sivut ovat vaikka hakemistossa /home/user/public_html, tiedosto voisi olla /home/user/mysql.php ja siihen voisi koodissa viitata suhteellisella polulla ../mysql.php.
Jos taas ajattelit ”suojata” tiedoston vaikka webhotellin ylläpidolta, unohda koko juttu: se ei ole realistisesti mahdollista.
Hah, jotenkin etäisesti olen tunnistavinani tuosta kirjautumiskoodista omaa kädenjälkeä. Eipä ole webbikoodausta tullut juurikaan tehtyä viimeaikoina, mutta muistelisin että yli 10 v sitten tuo ei näyttänyt ollenkaan niin pahalta kun nyt. Ei kai tuossa sinänsä mitään toiminnallista vikaa olekkaan, mutta kyllä php-koodaus on tuosta aika harppauksen tullut eteenpäin, esim. tuki olio-ohjelmoinnille, pdo yms :)
Hyväksymällä tuota paskaa et kehity koskaan. ( ͡⊙ ͜ʖ ͡⊙)
Ü
Itseasiassa kun tuo ajv:n nimimerkki pongahti esille, muistan että saattaapi olla joku sun tekemä alunperin. Ainakin kyseisellä nimimerkillä monta vinkkiä aikoinaan saanut ohjelmointiin. Edelleen samaa purkka koodia kirjoittelen omissa projekteissa mitkä ei niin haudan vakavia ole. Jokatapauksessa, kyseinen pätkä toiminut kyllä hyvin ja on juuri niin yksinkertainen käyttää että mäkin osaan.
Minäkin tuon ajv:n koodiksi tunnistin heti, sen verran tuli käytettyä tätä koodivinkkiä omissa projekteissa aikanaan.
Itse jo siirtynyt eteenpäin, mutta millos me nähdään päivitetty versio tuosta koodivinkistä? :)
Osa käytetyistä funktioista on jo uudemmissa php-versiossa poistettu.
Olisko vinkkejä saako tuota session katkasu ongelmaa mitenkään ratkastua? Nebula ei anna php:n asetuksia säädellä yhtään. Heidän osalta ainut ratkasu on dedikoitu palvelin jonka kustannukset on sitten X luokkaa nykyseen.
Eli tuo pitäis mielellään pysyä hengissä vaikka 8h kerralla.. Pystyykö sitä mitenkään keinotekosesti pitämään hengissä?
Onko siellä sitten Nebulan asettama oletus joku muu kuin 0, eli että istunto pysyy voimassa kunnes selain suljetaan?
Vai pitäisikö sen pysyä sen selaimen sulkemisen jälkeenkin?
Tuntuu oudolta tuo väitteesi ettei voisi muokata kun Nebulan ohjeissa kuitenkin lukee:
Nebula kirjoitti:
https://www.nebula.fi/fi/asiakkaille/ohje/
yritysten-verkkosivut/webhotellit/php-ohjelmointi
PHP-asetusten muuttaminenPHP-asetuksia voi muokata omalla php.ini -tiedostolla. Sijoita se esimerkiksi kotihakemistoosi, ja tee skriptien kanssa samaan hakemistoon tiedosto, jonka nimeät nimellä .htaccess, jossa on sisältönä (Jos hakemistossa on jo .htaccess-niminen tiedosto, lisää rivit olemassaolevan tiedoston alkuun!):
suPHP_ConfigPath /var/www/customers/kotihakemistosi
Tällöin PHP-skriptejä ajettaessa mahdolliset asetusmuutokset luetaan tiedostosta /var/www/customers/kotihakemistosi/php.ini
Ja eikö sitten myöskään ini_set toimi?
ini_set("session.cookie_lifetime","28800"); //8 tuntia
Ei paljoa evästeet auta, jos session tiedot poistetaan levyltä. En kyllä usko, että Nebula olisi virittänyt vanhenemisaikaa ihan pariin minuuttiin, koska siinä ei ole järkeä.
Niin no joo, PHP:n dokumentaation mukaan sessiontiedostot poistetaan oletusasetuksella 1440 sekunnin eli 24 minuutin kuluttua. :D
https://www.php.net/manual/en/session.
Jos et saa tavallisia istuntoja toimimaan, voit aina rekisteröidä oman istunnonkäsittelijän, jolloin voit hallita tarkalleen, mihin tiedot tallennetaan ja milloin niitä poistetaan.
Purkkaratkaisu on myös laittaa sivulle pieni iframe, jota päivitetään JavaScriptilla tai Refresh-otsikolla vaikka 23 minuutin välein, jolloin istunto säilyy, kunhan käyttäjä pysyy sivulla.
Toisaalta alkuperäisessä koodissa istuntoa käytetään typerästi. Jos kirjautuminen tallennetaan istuntoon, siihen voi hyvin tallentaa suoraan käyttäjän id:n, ja log_key on turha. Jos istunnon ainoa tarkoitus on kirjautuminen, ei kannata käyttää istuntoja, vaan voi ihan hyvin generoida käyttäjälle satunnaisen log_keyn ja tallentaa sen tavalliseen evästeeseen. Tällöin log_keyn alkuun kannattaa laittaa käyttäjän id törmäysten estämiseksi ja loppuun vahvasti satunnaista dataa kuten random_bytes(16).
Nebula asiakaspalvelu kirjoitti:
teillä on käyttössä jaettuna palvelinalustana toimiva Webhotel -palvelu johon on määritetty raja-arvot joita ei voi muuttaa. Mikäli teillä on tarvetta dedikoiduille juuri teille sopivilla asetuksilla voisi oma dedikoitu palvelinratkaisu olla sopivampi tai koodin optimointi Webhotellissa sopivaksi.
Näin vastasi nebula.
Sessio saa/pitääkin ehkä poistua kun selain suljetaan.
Tuon systeemin minkä rakensin, on sellainen että sitä käytetään päivisin kun tekee töitä ja täyttää lomaketta. Nyt jos lomakkeen avaa, ja rupeaa siihen hiljalleen tallentamaan tietoa ja vaikka 30min päästä kun se on valmis, painaa tallenna nappia niin se heittääkin ulos kun sessio ei ole voimassa. Tämä tapahtuu itseasiassa testien mukaan jo hieman yli 5min jälkeen. Eli aika lyhyt aika.
pitääpä tuo ini juttu vielä testata ja sitten kysyä nebulalta miksi sitä ei voisi käyttää kun kerran ohjeet näin kertoo.
Asia on aivan yksinkertainen: jaetussa järjestelmässä toinen taho (esimerkiksi Nebulan skripti) tuhoaa kaikki vanhentuneet istunnot oman raja-arvonsa mukaan, jolloin PHP:n asetusten muuttaminen yhdessä tiedostossa ei vaikuta tilanteeseen. Voit siis vaihtaa PHP:n asetuksia (kuten ohjeissa lukee), mutta siitä ei ole tässä tilanteessa hyötyä (kuten Nebulan asiakaspalvelu on sinulle jo kertonut). Turha sitä on Nebulalta enempää kysyä, olet jo saanut heiltä vastauksen.
Selitin jo kolme muuta vaihtoehtoa (oma käsittelijä, JS-kikka, turhan istunnon vaihto pelkkään evästeeseen), joilla voit ratkaista ongelmasi.
Tai sitten vaihtaa palveluntarjoajaa taas sellaseen mikä joustaa palvelussa.
Lisäys: Pystyiskö ajaxilla päivittää jotenkin tuota sessiota niin että se pysyis hengissä? Metabolix mainitsi tuon sivupäivityksen mutta siinä ei pysyis lomakkeen tiedot ilmeisesti tallessa jos se sivu päivitetään aina uudelleen.
Ehdotin, että päivität pientä iframea etkä koko sivua.
<iframe style="position: fixed; width: 1px; height: 1px; left: -10px; top: -10px;" src="session_start.php"></iframe>
<!-- session_start.php: session_start(); header("Refresh: 1200"); -->Kyllä voit pitää istuntoa yllä myös AJAXilla, jos haluat.
jQuery(function() { setInterval($.get("session_start.php"), 1200*1000); });
// session_start.php: session_start();Etusivu.php
<?php
session_start();
include("ylaosa.php");
?><!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1" />
<meta charset="iso-8859-1" />
<title>etusivu</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />
<meta content="" name="description" />
<meta content="" name="author" />
<!-- BEGIN PLUGIN CSS -->
<link href="assets/plugins/bootstrap-select2/select2.css" rel="stylesheet" type="text/css" media="screen"/>
<link href="assets/plugins/jquery-slider/css/jquery.sidr.light.css" rel="stylesheet" type="text/css" media="screen"/>
<link href="assets/plugins/jquery-datatable/css/jquery.dataTables.css" rel="stylesheet" type="text/css"/>
<link href="assets/plugins/boostrap-checkbox/css/bootstrap-checkbox.css" rel="stylesheet" type="text/css" media="screen"/>
<link href="assets/plugins/datatables-responsive/css/datatables.responsive.css" rel="stylesheet" type="text/css" media="screen"/>
<!-- END PLUGIN CSS -->
<!-- BEGIN CORE CSS FRAMEWORK -->
<link href="assets/plugins/boostrapv3/css/bootstrap.min.css" rel="stylesheet" type="text/css"/>
<link href="assets/plugins/boostrapv3/css/bootstrap-theme.min.css" rel="stylesheet" type="text/css"/>
<link href="assets/plugins/font-awesome/css/font-awesome.css" rel="stylesheet" type="text/css"/>
<link href="assets/css/animate.min.css" rel="stylesheet" type="text/css"/>
<!-- END CORE CSS FRAMEWORK -->
<!-- BEGIN CSS TEMPLATE -->
<link href="assets/css/style.css" rel="stylesheet" type="text/css"/>
<link href="assets/css/responsive.css" rel="stylesheet" type="text/css"/>
<link href="assets/css/custom-icon-set.css" rel="stylesheet" type="text/css"/>
<!-- END CSS TEMPLATE -->
<script>
<iframe style="position: fixed; width: 1px; height: 1px; left: -10px; top: -10px;" src="session_start.php"></iframe>
</script>
</head>session_start.php
<? session_start(); header("Refresh: 180"); ?>
Ei auttanut, jotain väärin?
Ei toiminut myöskään tuolla jqueryn pätkällä, kun korvasin tuon iframen <script>"jqueryn koodi"</script>.
Aika äkkiä tuntuu katkovan kun kerkiää leivän tekemään niin on jo katki.
Kuten varmaan selaimen virhekonsoli olisi näyttänyt, iframe ei ole JavaScriptia eikä siis tietenkään kuulu script-tagien sisään eikä head-osaan vaan muualle sivulle, esimerkiksi sivun loppuun.
JS-koodiini on tullut virhe, puuttuu yksi funktiolohko. Alla on korjattu JS-koodi:
jQuery(function() {
setInterval(
function() { $.get("session_start.php") },
20 * 60 * 1000
);
});
// session_start.php: session_start();Muutenkin, jos "ei toimi", katso selaimen virhekonsolia ja verkkolokia ja selvitä sieltä, millä tavalla "ei toimi".
Nyt toimii, suurkiitos.
Miksi viestini sensuroitiin..¨
Kun kerta MD5 on niin mahdottoman turvaton Grez löytää vastineen helposti ja kätevästi:
c0102e96b180fe4334333b6125793ece
Luulisin että se poistettiin koska siitä jäi epäselväksi että mitä ajoit sillä takaa. Edelleen jää epäselväksi.
Grez kirjoitti:
– – siitä jäi epäselväksi että mitä ajoit sillä takaa. Edelleen jää epäselväksi.
Itse ymmärrän tuon haasteena sulle, että tuo pitäisi selvittää kun "se on mahdottoman turvaton".
qeijo kirjoitti:
Kun kerta MD5 on niin mahdottoman turvaton – –
Jokaiselle MD5:lle ei helposti löydy vastinetta, mutta ei se tarkoita, että MD5 olisi turvallinen. Satunnaisistakin merkkijonoista jopa 9-merkkisiä löytyy usein ihan vain MD5-tiivisteellä googlettamalla, sanoja tai sananmuunnoksia sisältävistä salasanoista pidempiäkin (esimerkiksi näin tai näin). Satunnaisen suolan tarve on jo tällä perusteltu. Sitten itse MD5:n turvattomuudesta (suolalla tai ilman) voidaan todeta, että nykyaikaisella kotikoneella saa parissa päivässä käytyä läpi 10-merkkiset salasanat merkistöllä a-z tai vastaavan määrän erilaisten kaavojen mukaisia salasanoja. Iteroinnin tarve haun hidastamiseksi on ilmeinen.
Edellä olevat ongelmat välttää helposti käyttämällä valmiita salasanafunktioita (password_hash, password_verify, password_needs_rehash). Suolauksen ja iteroinnin kehittely uudestaan itse on turhaa työtä.
qeijo kirjoitti:
Miksi viestini sensuroitiin
Sensurointi ja typerien viestien poisto ovat kaksi eri asiaa. Viesti sisällöllä ”MD5 ? 12a604c8e392a7f1866934d50cf4f699” ei ole ymmärrettävä tai järkevä. Onneksi toiseen yritykseen osasit kirjoittaa vähän saatetekstiäkin.
Anteeksi että yliarvioin teitä. Olisi pitänyt olla viestissäni tarkempi. Muotoilen uudestaan:
Kun kerta MD5 on niin mahdottoman turvaton Grez löytää vastineen helposti ja kätevästi seuraavalle MD5 hasille.
c0102e96b180fe4334333b6125793ece
Se että Google löytää tiivisteen ei ole mielenkiintoista.
Suolan käyttö pätee muidenkin tiivistealgoritmien osalta, joten voisitte yleisesti ottaen suosia sen käyttöä.
Md5 ei ole sen kummempi suolan kanssa kuin esim. SHAn mutta putkalaisten asiantuntijoiden mielestä se on vähintäänkin syöpään verrattavissa.
qeijo kirjoitti:
Anteeksi että yliarvioin teitä. Olisi pitänyt olla viestissäni tarkempi.
Joo itsekin yliarvioin sinua kun
a) luulin että viestissäsi olisi ehkä joku pointti
b) että et jaksaisi jankata enää sen jälkeen kun Metabolix oli jo selittänyt sinulle miksi ketään ei kiinnosta että laitat jonkun satunnaisen MD5-tiivisteen jolle on haastavaa löytää vastine.
c) En arvannut että ihan tosissaan haluat väittää että "md5 ilman suolaa on aivan hyvä käytäntö".
qeijo kirjoitti:
Kun kerta MD5 on niin mahdottoman turvaton Grez löytää vastineen helposti ja kätevästi seuraavalle MD5 hasille.
Se, että salasanojen tiivistäminen pelkällä md5:llä ilman suolaa on huonoa tietoturvaa, ei toki millään tavalla tarkoita sitä että riittävän vaikean salasanan pelkälle md5-tiivisteelle olisi helppo löytää vastaava salasana. Suolaamista ja parempia tiivistealgoritmeja käytetään juuri sen vuoksi, että helppojakaan salasanoja ei olisi triviaali murtaa.
qeijo kirjoitti:
Suolan käyttö pätee muidenkin tiivistealgoritmien osalta, joten voisitte yleisesti ottaen suosia sen käyttöä.
Alkuperäinen viestini oli että "ongelma, että salasana tiivistetään MD5:llä ilman suolaa". Eli tuosta vähän kengänpohjaa älykkäämpi voisi päätellä että nimenomaan suosittelin suolan käyttöä esim. MD5:n kanssa. Esimerkiksi suosittelemassani BCryptissä sen sijaan suolaus on sisäänrakennettu pakettiin, joten sitä ei käyttäjän tarvitse itse miettiä. Suosittelin BCryptin käyttöä, koska se soveltuu yleisesti ottaen paremmin salasanojen tiivistämiseen kuin perustiivistealgoritmit. (Sillä on helpompi ja tehokkaampi varautua myös tulevaan)
qeijo kirjoitti:
Md5 ei ole sen kummempi suolan kanssa kuin esim. SHAn mutta putkalaisten asiantuntijoiden mielestä se on vähintäänkin syöpään verrattavissa.
En kyllä ymmärrä miksi tässä asiassa sitten minuun viittaat, kun en ole SHA:sta mitään puhunut. Toki SHA on parempi kuin MD5, mutta jopa MD5 suolattuna on jo "riittävä" toisin kuin tuon MD5 ilman suolaa, jonka käyttöä kritisoin.
Ja tän viestin sävy nyt on kategoriassa "niin metsä vastaa..."
Tämä on liian helppoa. Röff röff.
Aihe on lukittu, joten siihen ei voi vastata.