Suositulta keskustelufoorumilta vuoti yli 73.000 käyttäjän tiedot - tarkista oletko joukossa

jotain28. November, 2011 9:451/22

Mielenkiintosta, mihkään noista palveluista en oo rekisteröitynyt, mut silti tuo tarkistuspalvelu löytää mun sähköpostiosoitteen.. :/

Zoomst28. November, 2011 9:562/22

*köh* https://twitter.com/#!/AnonFinland */köh*

Ketola28. November, 2011 10:253/22

Lainaus, alkuperäisen viestin kirjoitti jotain:

Mielenkiintosta, mihkään noista palveluista en oo rekisteröitynyt, mut silti tuo tarkistuspalvelu löytää mun sähköpostiosoitteen.. :/

Tarkistuspalvelu on päivitetty näyttämään erikseen tarkat osumat ja "villin haun osumat". Eli jos osoite etunimi.sukunimi@osoite.fi löytyy listalta, kertoo haku "sukunimi@osoite.fi" että hakutermi löytyi osana pidempää osoitetta ja haku "etunimi.sukunimi@osoite.fi" kertoo että osoite löytyi (sellaisenaan) listalta.

Toivottavasti tämä parannus auttaa varmistamaan, onko oma osoite listalla! Kyseessä on niin suuri määrä osoitteita, että lyhyet osoitteet (esim. oma henk.koht. osoitteeni) löytyy listalta osana pidempiä osoitteita.

jotain28. November, 2011 10:384/22

Lainaus, alkuperäisen viestin kirjoitti Ketola:

Lainaus, alkuperäisen viestin kirjoitti jotain:

Mielenkiintosta, mihkään noista palveluista en oo rekisteröitynyt, mut silti tuo tarkistuspalvelu löytää mun sähköpostiosoitteen.. :/

Tarkistuspalvelu on päivitetty näyttämään erikseen tarkat osumat ja "villin haun osumat". Eli jos osoite etunimi.sukunimi@osoite.fi löytyy listalta, kertoo haku "sukunimi@osoite.fi" että hakutermi löytyi osana pidempää osoitetta ja haku "etunimi.sukunimi@osoite.fi" kertoo että osoite löytyi (sellaisenaan) listalta.

Toivottavasti tämä parannus auttaa varmistamaan, onko oma osoite listalla! Kyseessä on niin suuri määrä osoitteita, että lyhyet osoitteet (esim. oma henk.koht. osoitteeni) löytyy listalta osana pidempiä osoitteita.

Jees, kiitoksia.. :) Eli oli tosiaa osa pitempää osoitetta, en ois vaa ihan heti uskonu et jonkun toisen sähköpostiosoite loppuu tuollain, mut näköjää..

bfr28. November, 2011 11:425/22

Käsittämätöntä millaisia salasanoja ihmiset käyttävät. Sanakirjasta löytyviä sanoja, nelinumeroisia lukuja(joista osa on luultavasti vielä automaattikorttien ja puhelimien PIN:ejä), lyhyitä ihmisten nimiä(luultavasti poika- ja tyttöystäviä, lapsia jne.).

Ansaitsevatkin saada pikku näpäytyksen.

overdose28. November, 2011 11:446/22

Oliko tämä nyt jo kolmas tietovuoto pienen ajan sisällä? Onko ylläpitäjät lomalla vai missä mättää, kun ei saada sitä tietoturvaa kuntoon. Salaisivat edes ne salasanat.

ArskaVi28. November, 2011 11:497/22

"Vuodettu lista..."

VUODETTU?!?

Kyseessä on varkaus.

V-A-R-K-A-U-S

Vrt:
"Pankki vuoti rahansa holvistaan kahdelle vuodon vastaanottaneelle miehelle viime yönä klo 03.00 aikoihin".

repino28. November, 2011 11:518/22

Mikäli haluat, niin salasanaa kannatta vaihtaa kerran vuorokaudessa, kuten armeijan laitteilla tehtiin jo 90-luvulla Nokian laitteilla. Salasanan pituus oli 25 merkkiä, ja silloinkin oli laskettu, että sen purkuun menee vain muutama vuorokausi, mutta silloin viestit olivat jo vanhoja.
Niin jos ketään kiinnostaa niin salaajille löytyy aina töitä.
Yleisesti, ei kannata mitään kovin tärkeää asiaa laittaa nettiin. Tosin tuskin kellään on syytä tulla paranoidiksi näissä jutuissa.

Ketola28. November, 2011 11:559/22

Lainaus, alkuperäisen viestin kirjoitti ArskaVi:

"Vuodettu lista..."

VUODETTU?!?

Kyseessä on varkaus.

V-A-R-K-A-U-S

Vrt:
"Pankki vuoti rahansa holvistaan kahdelle vuodon vastaanottaneelle miehelle viime yönä klo 03.00 aikoihin".

Tässä tapauksessa tietovuoto-termi on sikäli oikeutettu, että tiedot saatiin varastettua ilmeisimmin puutteellisesta tietoturvasta johtuen. Toki kyseessä on joka tapauksessa tietomurto/tietovarkaus, joka todennäköisesti johtaa poliisitutkintaan. Tietovuoto siitä tulee kuitenkin siinä vaiheessa kun varastetut tiedot laitetaan julkiseen levitykseen.

Potilastiedot varastetaan sairaalasta = tietovarkaus

Potilastiedot varastetaan sairaalasta ja julkistetaan = tietovuoto

Ketola28. November, 2011 12:0010/22

Lainaus, alkuperäisen viestin kirjoitti repino:

Mikäli haluat, niin salasanaa kannatta vaihtaa kerran vuorokaudessa, kuten armeijan laitteilla tehtiin jo 90-luvulla Nokian laitteilla. Salasanan pituus oli 25 merkkiä, ja silloinkin oli laskettu, että sen purkuun menee vain muutama vuorokausi, mutta silloin viestit olivat jo vanhoja.

Käsittääkseni sanomalaitteen (ja parsan) salausta muutettiin ensisijaisesti siksi, ettei "rakkaan rajanaapurin" kuuntelijat saisi riittävän kattavaa otosta erilaisia viestejä ja kykenisi niiden avulla purkamaan salausalgoritmiä. Tämän vuoksi oli myös kiellettyä samansisältöisten viestien lähettäminen eri avaimilla.

Todennäköisesti salaus on kyllä jo murrettu ja purkulaitteita käytössä niillä, joita viestien kuuntelu kiinnostaa.

JoniS28. November, 2011 12:0311/22

tiedä onkos jo kysytty mutta mites AD:n laita, että lähteekö täältäkin tiedot yhtä "helposti" kävelemään vääriin käsiin?

TuPP328. November, 2011 12:2612/22

Taitaako muuten nämäkin kaikki olla ala-astelaisten ATK-tunnilla suorittamia SQL-injektioita tai sivujen salasanasuojattomia MySQL-tietokantoja?
Hirveitä skandaalimurtoja julistetaan ja kaikki on varpaillaan, vaikka mitään pelättävää ei oikeasti ole ellei ole rekkaillut itseään kaikkine tietoineen 4 kävijää/vuosi sivustoille.
Itse ainakin käytän eri salasanaa tärkeissä ja sitten yhtä ja samaa kaikissa turhissa palveluissa joissa ei ole mitään menetettävää.
Kyseessä ei ole mikään tietomurto jos sivun plaintext muotoisen salasanalistan tarkistamiseen ei edes vaadita salasanaa.
Miksi helvetti ne nyt ei edes hashaa niitä passuja? Tai simppelisti vain estä tuota SQL-injektiota?
Sitähän nämä ala-astelaiset nimenomaan haluavat kertoa, joidenkin pikkusivujen tietoturva ontuu naurettavan paljon.

dRD28. November, 2011 12:3213/22

Lainaus, alkuperäisen viestin kirjoitti munkki666:

tiedä onkos jo kysytty mutta mites AD:n laita, että lähteekö täältäkin tiedot yhtä "helposti" kävelemään vääriin käsiin?

Tyypillisin tapa murtautua verkkopalveluihin lienee SQL injection -tekniikka. Käytännössä tekniikka tarkoittaa sitä, että joku sivuston yksittäinen sivu on koodattu, niin että sisääntulevista parametreistä ei parsita "vaarallisia" merkkejä pois.

Esimerkkinä siis vaikka joku palautekaavake (esim. palaute.php), joka lähettää HTTP:n yli seuraavalle sivulle (esim. tallenna_palaute.php) kaksi kenttää:

palauteteksti
lahettajannimi

Ja sitten tuo tallenna_palaute.php tallentaa tuon lähetetyn palautteen tietokantaan myöhempää käsittelyä varten:

---

INSERT INTO feedback(feedbacktext, sentby)

VALUES('kaavakkeelta-tullut-palauteteksti-muuttuja', 'kaavakkeelta-tullut-lahettajannimi-muuttuja')

---

Okei. Tässä tulee sitten se tietoturva osuus. SQL, speksien ja oletusarvon mukaan, voidaan "katkaista" useampaan eri lausekkeeseen puolipisteellä. Nyt, haxx0rina oletetaan, että käyttäjätaulu on nimeltään 'users' ja halutaan vaikka vain tehdä pahaa ja tuhotaan tuo koko taulu. Silloin SQL on muotoa:

---

DROP TABLE users

---

Nyt, hyväksikäytetään sitä, että puolipisteet tarkoittavat uutta komentoa SQL:ssa ja heittomerkki katkaisee stringin. Käytetään tuota palaute.php -kaavaketta ja annetaan sille arvot:

palauteteksti: You have been haxxored!
lahettajannimi: seppo'); DROP TABLE users;

Tällöin tuo tallenna_palaute.php tekee seuraavan rimpsun:

---

INSERT INTO feedback(feedbacktext, sentby)

VALUES('You have been haxxored!', 'seppo'); DROP TABLE users

---

Eli tallennetaan annettu palaute oikein, mutta ajetaan sen jälkeen koodi, joka tuhoaa koko käyttäjätiedot sisältävän taulun.

Vastaavilla kuvioilla, hieman soveltaen, voidaan hakea esim. käyttäjätaulun koko sisältö ja saada sivu tulostamaan se sisältö sellaisenaan. Ainoat tavat estää tuontyyppinen kikkailu, ovat:

1) Poistetaan tai escapoidaan _aina_ heittomerkki ja muut vastaavat SQL:n kannalta erikoismerkit kaikista sisääntulevistateksteistä, koodin päässä.

2) Rajataan tietokannan käyttöoikeutta niin, että esim. DROP -komentoa ei voida käyttää sivuston sivujen kautta, vaan ainoastaan tietokannan ylläpidon kautta.

3) Salataan salasanat aina, MD5/SHA1 + salt -yhdistelmällä, jolloin luettavaa salasanadataa ei ole olemassakaan.

...ongelma tulee siitä, että laajemmalla saitilla, on tuhansia eri sivuja, joista jokainen sivu tekee tyypillisesti 2-10kpl SQL -kyselyitä. Kaikkien noiden kymmenien tuhansien SQL-kyselyiden tarkistaminen helppojen ja monimutkaisempien SQL injection -tapojen kannalta on hyvin, hyvin hidasta ja vaivalloista. Usein ainakin yksi, harvoin käytetty template tuppaa unohtumaan tuollaisen testauksen ulkopuolelle. Jolloin ainoa täysin varma tapa estää salasanojen vuoto on huolehtia kohta 3 kuntoon, eli salasanat eivät saa olla koskaan talletettuna luettavassa muodossa.

Eli, teoriassa, käyttäjänimien ja sähköpostiosoitteiden vuotaminen meidänkin palvelusta on mahdollista, vaikkakin olemme 99.999% varmoja siitä, että olemme tilkinneet kaikki mahdolliset SQL injection -aukot sivuiltamme. Lisäksi käymme aika ajoin wanhaakin koodia läpi ja pyrimme etsimään erilaisia "aivopieruja" koodin seasta. Mutta salasanojen vuotaminen taas ei ole mahdollista, koska emme niitä mihinkään luettavassa muodossa tallenna.

Ketola28. November, 2011 12:3814/22

Petteri tuossa yllä vastasikin melko kattavasti koodin puolesta. Tämän lisäksi varsinaiset palvelimet, joilla tiedot (ja niiden varmuuskopiot) sijaitsevat on suojattu monin eri teknisin keinoin. Näitä keinoja ovat mm. palomuurit, vahvat salasanat ja salausavaimet sekä erilaiset aktiiviset torjuntakeinot.

Lumikki28. November, 2011 13:0715/22

Lainaus:

Oliko tämä nyt jo kolmas tietovuoto pienen ajan sisällä? Onko ylläpitäjät lomalla vai missä mättää, kun ei saada sitä tietoturvaa kuntoon. Salaisivat edes ne salasanat.

Ei ne ole lomalla, vaan erillaisten palveluiden tietoturva taso on todellisuudessa ihan perseestä. Siis kysessä on yleinen ongelma joka koskee todennäköisesti suurinta osaa palveluja. Palvelujen rakentajat eivät välitä paskaakaa tai ymmärrä tietoturvan päälle. Halutaan vain palvelu joka toimii ja on helppo laittaa pystyyn, tietoturvan kustannuksella.

Hakkerit vain käyttävät nyt saamaansa julkisuutta hyväkseen tuodakseen ongelma esille, joka on vaivannut suurinta osaa palveluja jo vuosia.

qwqwqhhjj3 (vahvistamaton)28. November, 2011 13:4616/22

Lainaus:

2) Rajataan tietokannan käyttöoikeutta niin, että esim. DROP -komentoa ei voida käyttää sivuston sivujen kautta, vaan ainoastaan tietokannan ylläpidon kautta.

Tämähän nyt pitäisi olla perusasetus joka tapauksessa. Millekään prosessille ei pitäisi antaa enempää oikeuksia kuin ne tarvitsevat. Ihan siitä huolimatta vaikka sovellus olisikin muuten tietoturvallinen.

Lainaus:

3) Salataan salasanat aina, MD5/SHA1 + salt -yhdistelmällä, jolloin luettavaa salasanadataa ei ole olemassakaan.

Toikin on asia, jota ei ehkä kannattaisi lähteä keksimään itse uudestaan, vaan kannattaisi käyttää systeemikirjastossa valmiiksi olevaa crypt()-funktiota, joka käyttää salttia, ja uusimmissa versioissa käytetty hash-funktiokin on oletuksena SHA-512.

asdasdsafcfv (vahvistamaton)28. November, 2011 13:4717/22

Lainaus:

...ongelma tulee siitä, että laajemmalla saitilla, on tuhansia eri sivuja, joista jokainen sivu tekee tyypillisesti 2-10kpl SQL -kyselyitä.
Kaikkien noiden kymmenien tuhansien SQL-kyselyiden tarkistaminen helppojen ja monimutkaisempien SQL injection -tapojen kannalta on hyvin, hyvin hidasta ja vaivalloista.

Ongelma tulee siitä, että sivusto on tehty päin persettä. Vaikka käytettäiskin tuota PHP:n oletus mysql-apia, niin noihin sql-kyselyihin olisi jo alunperin pitänyt tehdä joku oma välikerros, joka huolehtii tuon kyselyn validoinnista yms. eikä millään noilla sadoilla sivuilla tulisi käyttää tietokantaa suoraan tuon välikerroksen ohi. Sitten korjaus voitaisiin tehdä vain tuohon yhteen paikkaan.

Lainaus:

Jolloin ainoa täysin varma tapa estää salasanojen vuoto on huolehtia kohta 3 kuntoon, eli salasanat eivät saa olla koskaan talletettuna luettavassa muodossa.

Eikun noiden kaikkien kohtien tulisi pyrkiä pitämään kunnossa eikä vain pelkkä salasanojen hashaus.

dsfsdfa (vahvistamaton)28. November, 2011 13:4818/22

Lainaus:

1) Poistetaan tai escapoidaan _aina_ heittomerkki ja muut vastaavat SQL:n kannalta erikoismerkit kaikista sisääntulevistateksteistä, koodin päässä.

Ei tuota noin kannata tehdä. Lähes kaikkien tietokantojen oletus-API sisältää prepare/bind/exec mekanismin (Ja monissa kannoissa tuo on jopa ainoa tapa käyttää niitä)

Tämä puheena oleva ongelma koskee lähinnä PHP:ta, kun siinä on muutettu tuo API huonommaksi, ja sitä käytännössä käytetään tuolla mainitsemallasi tavalla. Myöhemmin PHP:henkin on lisätty mysqli-api, jossa on taas tajolla tuon prepare/bind/execute, ja sitä käyttäen SQL-injektiota ei saa aikaiseksi, vaikka inputiksi syöttäisi mitä eikä tarvi erikseen huolestua erikoismerkeistä. (Toki jos API:ssa on joku bugi, niin sitten tuotakin kautta pääsee sql-injektoimaan, mutta sen korjaus silti tehdään vain yhteen paikkaan)



Tyhmä vekotin, kun valitti,että mun vastaus on liian pitkä. piti laittaa sitten kolme viestiä

dRD28. November, 2011 14:0319/22

Lainaus, alkuperäisen viestin kirjoitti qwqwqhhjj3:

Lainaus:

2) Rajataan tietokannan käyttöoikeutta niin, että esim. DROP -komentoa ei voida käyttää sivuston sivujen kautta, vaan ainoastaan tietokannan ylläpidon kautta.

Tämähän nyt pitäisi olla perusasetus joka tapauksessa. Millekään prosessille ei pitäisi antaa enempää oikeuksia kuin ne tarvitsevat. Ihan siitä huolimatta vaikka sovellus olisikin muuten tietoturvallinen.

Jep, näinhän sen _pitäisi_ mennä, mutta ei mene :-) Aikanaan tein työkseni verkkosivujen kehitystä ja tuli nähtyä jos jonkinlaista infraa käytössä, isoissakin puljuissa. Usein web-koodaajana noista kun valitti, sua ei noteerattu mitenkään. Joten, ainoa tapa varmistaa siinä tapauksessa, että infraan et voi vaikuttaa, on varmistua SQL:n escapoinnista ja siitä, että passuja ei pistetä kantaan muutakuin salattuna/non-reverse-readablena.

Lainaus:

Lainaus:

3) Salataan salasanat aina, MD5/SHA1 + salt -yhdistelmällä, jolloin luettavaa salasanadataa ei ole olemassakaan.

Toikin on asia, jota ei ehkä kannattaisi lähteä keksimään itse uudestaan, vaan kannattaisi käyttää systeemikirjastossa valmiiksi olevaa crypt()-funktiota, joka käyttää salttia, ja uusimmissa versioissa käytetty hash-funktiokin on oletuksena SHA-512.

Toki, mutta tässä esimerkissä nyt lähinnä halusin hahmottaa tuota kokonaiskuvaa. Plus tietty tuoda sen esille, että web-ohjelmoinnissa käytettäviä kieliäkin on satoja, joista osassa nuo funktiot ovat olemassa valmiina, osassa ne pitää tehdä itse.

Lainaus, alkuperäisen viestin kirjoitti asdasdsafcfv:

Lainaus:

Jolloin ainoa täysin varma tapa estää salasanojen vuoto on huolehtia kohta 3 kuntoon, eli salasanat eivät saa olla koskaan talletettuna luettavassa muodossa.

Eikun noiden kaikkien kohtien tulisi pyrkiä pitämään kunnossa eikä vain pelkkä salasanojen hashaus.

Toki näin, mutta jälleen, realistina.. Kohdat 1 ja 2 ovat sellaisia, että niihin tulee pyrkiä, mutta joista ne aukot löytyvät, jos ovat löytyäkseen. Kohdan 3 laittamalla kuntoon kohdat 1 ja 2 menettävät tavallisen käyttäjän tietoturvan näkökulmasta valtaosan merkityksestään. Toki tämä ei poista kohtien 1 ja 2 tärkeyttä tietoturvan suhteen, mutta ymmärtänet pointin?

Ibanez9028. November, 2011 15:3820/22

Omat tunnukset ei ole viellä ollut yhellekään listalla. Vuotoja on kuitenkin tapahtunut jo aika monta. Sitä hetkeä odotellessa kun omat tiedot löytyy jostain.

Olisi muuten hyvä jos pystyisi etsimään salasanan perusteella että onko oma salasana jonkun muun käytössä. Noin voisi myös löytää sen että onko joku vanha käyttäjä tunnus esimerkiksi tuolla kun aikoinaan käytti samaa salasanaa monessa paikkaa ym.

fasdfewrewqg (vahvistamaton)28. November, 2011 17:2821/22

Lainaus, alkuperäisen viestin kirjoitti Ibanez90:

Olisi muuten hyvä jos pystyisi etsimään salasanan perusteella että onko oma salasana jonkun muun käytössä.

Millä perusteella luokittelisit saitin sellaiseksi, jonne uskallat salasanasi kirjoittaa ilman, että se tallennetaan johonkin haxoreiden käytössä olevien salasanojen listalle, johon sitten osataan laskea valmiiksi HASH-tiiviste ja lisätä se noihin "rainbow tableihin", joista se sitten seuraavan haxoroidun saitin tapauksessa löytyy samantien.

juppe2228. November, 2011 19:2922/22

On kyllä outoa, näin isoja rekistereitä säilytellään ihan plain textinä. Tässä olisi lainsäätäjillä kyllä suomessakin töitä, koska on kyllä outoa, että näistä ei joudu rekisterin pitäjät vastuuseen, vaikka ihan perus tietoturva-asioita on laiminlyöty ihan kunnolla. Sitten kyllä kaikkia mahdollisia lakeja säädetään ties mihin, mutta ihmisten tietojen vuotaminen on kuitenkin ihan laillista, vaikka näissäkin tapauksissa tosiaan hash:aamalla salanat olisi kuitenkin hyvän salasanan valinneet välttyneet tältä ongelmalta. Tai enpä usko, että kukaan jaksaa alkaa bruteforcettamaan auki yksittäistä random salasanaa hasheista, joihin on lisätty vielä "suolaakin".

Nykypäivänä, jos haluaa välttyä näiltä ongelmilta (kun tietoja säilytellään miten sattuu), niin kaikkia palveluita kannattaa käyttää simppelisti siten, että joka ikinen kerta kirjautuessaan nollaa salasanansa ja käyttää jotain random generoitua salasanaa. Toki jos haluaa säästää vähän mailien määrässä, niin laittaa rastin ruutuun "pidä minut kirjautuneena", niillä koneilla, joihin ei ole muilla pääsyä.

Google hoitaa tämän asian kyllä esimerkillisesti, jos ottaa tililleen käyttöön kahden vaiheen varmennuksen. Menee lähelle suomessa toimivien pankkien verkkopalvelujen tasoa.