Mikä olisi suositeltava salaustapa, joka salaa siten että salattu stringi on xml-kelpoista dataa? En etsi pelkkää md5:tä tai binhexiä, pitää pystyä purkamaan salaus.
Salaa erikseen ja muuta sitten XML-kelpoiseksi vaikka base64_encodella.
Metabolix kirjoitti:
Salaa erikseen ja muuta sitten XML-kelpoiseksi vaikka base64_encodella.
Kiitos! Tuo toimii tähän tarkoitukseen hyvin.
Mihin tulossa? Eli olisiko mahdollista tarjoilla xml-tiedostoa vain kirjautuneille?
Lebe80 kirjoitti:
Mihin tulossa? Eli olisiko mahdollista tarjoilla xml-tiedostoa vain kirjautuneille?
On jo tullut. Tekemässäni xml-foorumissa on tosin kirjautumissysteemi ja lisäksi xml-tiedostot sijaitsee .htaccess suojatussa hakemistossa, mutta minusta on parempi salata tiedot, jotka ei kuulu muille.
Minulla on työn alla nyt vieraskirja, jossa ei ole kirjautumista, laitan siihenkin joidenkin tietojen salauksen. Varsinkin niiden, jotka ei ole vapaasti luettavissa vieraskirjan sivuilta, kuten ip ja sähköposti.
Mä taas pistäisin tiedot rivitietona tietokantaan, josta tulostettaisiin näkyville vain ne rivit, joihin on "pääsy".
Lebe80 kirjoitti:
Mä taas pistäisin tiedot rivitietona tietokantaan, josta tulostettaisiin näkyville vain ne rivit, joihin on "pääsy".
Käsität väärin. Noin minäkin olen tehnyt saman foorumin mysql-versioon. Mutta minusta on suuri virhe luottaa siihen, että kun on käytössä mysql-tunnukset niin sinne meneviä tietoja ei tarvitse mitenkään salata. Pitäisi olla tuoreessa muistissa muutaman kuukauden takaiset tietomurrot Suomessa. Ongelmia tuli nimenomaan tuollaisen puutteellisen salaussysteemin vuoksi, samoin muutama vuosi sitten tapahtunut murto suomi24:n käyttäjä-tietokantaan.
Nämä minun xml-hommat ovat tekemieni ohjelmien xml-versioita.
pistemies kirjoitti:
Pitäisi olla tuoreessa muistissa muutaman kuukauden takaiset tietomurrot Suomessa. Ongelmia tuli nimenomaan tuollaisen puutteellisen salaussysteemin vuoksi,
Pitäisi myös ymmärtää vähän perusasioita, ennen kuin menee tuollaista väittämään. Tietomurroissa suurin vika ei ollut siinä, miten tiedot oli tietokantaan tallennettu. Suurin vika oli, että joku asiaton edes pääsi tietokantaan. Jos tietokantaa käsitellään oikein ja turvallisesti, sen tiedot ovat turvassa eikä niitä tarvitse millään tavalla salata. Optimitilanteessa jopa salasanojen suolaus on tarpeetonta, mutta toki niiden kohdalla on perusteltua noudattaa tiettyä varovaisuutta.
Pistemies: ymmärrän kyllä sen, että jos sun "koko tietokanta" on satunnaisen käyttäjän saatavilla, niin se onkin typerää että se on selkokielisenä... mutta sitä en ymmärrä miksi koko tietokanta edes on satunnaisen käyttäjän saatavilla... uskon enemmänkin, että sinulla on ihan perustavaa laatua oleva suunnitteluvirhe "xml-hommassasi" jos tarjoilet koko tiedostoa kaikille.
Jos taas tarvitset datan xml-muodossa esim. erilliselle skriptille, niin eikö data voi edelleenkin olla rivitietona tietokannassa, josta se tarjoillaan ilman ylimääräisiä rivejä vaikka sitten php-tulkin kautta xml-muotoon (esim. Käyttäjä A:lle tulostuu vain hänelle sallitut rivit).
Ja muista valita "hommiisi" oikeat työkalut ettet ala keksimään pyörää uudelleen ja menemään sillä perse edellä puuhun... Pitäisi olla tuoreessa muistissa muutaman kuukauden takaiset tietomurrot Suomessa. ;)
Eli kuten tuossa ylläkin vihjailtiin, niin tietokannasta murtamiseen tarvitaan tietokannan tunnarit ja salasana. Jos taas itse sovelluksessa on hakkerin mentävä aukko, niin ei siinä enää auta sovelluksessa oleva automaattisesti purkautuva salaus.
Myös koko tiedoston salaamisella onnistut pahimmassa tapauksessa korruptoimaan koko "tietokannan", kun se ei jonkin epäkelvon merkin ansiosta käännykkään selkokieliseen muotoon.
Kiitos mielenkiintoisista kommenteista.
Minulla palvelimella on vahva salasana ja lisäksi salasanat sijaitsee hakemistossa, jonka salasanaa en tiedä edes minä (loin sen cpanel-generaattorilla).
Lebe80: En salaa koko tiedostoa, vain xml-tagien välissä olevan datan "selkokielisenä" eli muutan salauksen yllä mainitulla base64_encodella.
qeijo: En oikein ole varma, mitä tarkoitit tuolla loppuhuomautuksella. Tarkoititko xml-tiedoston ominaisuuksia vai yleensä tiedostoon tallennettavan datan salaamista.
Mitä taas tulee tuohon xml-tiedoston käyttämiseen tavallisen txt-tiedoston sijasta, niin kyllä sen saa minulta täydet pisteet 10-0. Sen verran selkeämpää on php-skripti jota kirjoitetaan.
Otetaan pieni esimerkki:
<?php
$vk = $xml->GetXMLTree($tiedosto);
$viestit = $vk["VIERASKIRJA"][0]["VIESTI"];
$viestit = array_reverse($viestit);
# ---------
# väliin halutut html-muotoilut
for($i=0;$i<count($viestit);$i++){
echo $viestit[$i]["KIRJOITTAJA"][0]["value"];
# väliin halutut html-muotoilut
echo $viestit[$i]["PVM"][0]["value"];
# väliin halutut html-muotoilut
echo replace($viestit[$i]["DATA"][0]["value"]);
# jne.
/* paljon selkeämpää kuin
epämääräisten solunumeroiden käyttäminen tulostessa */
}
?>Ps. Kun on kyse tällaisista ohjelmista, jotka menee yleiseen jakeluun, hakemistojen ja mysql-yhteyksien salaus ei ole enää kiinni minusta.
Jos tuo koodinpätkä kuvastaa oikeaa koodiasi, niin onkohan taulukoissa jokin pahempikin suunnitteluvirhe?
Olettaen, että $viestit[$i] on yksi viesti, niin et kai ole laittanut kirjoittajaa paikkaan $viestit[$i]["kirjoittaja"][0]["value"]? Ehkä $viesti[$i]["kirjoittaja"] olisi huomattavasti selkeämpi ja helpompi.
array (
0 => array(
pvm => array(
0 => array(
value => ...
)
),
kirjoittaja => array(
0 => array(
value => ...
)
)
)
)
vs.
array (
0 => array(
pvm => ...,
kirjoittaja => ...
)
)Tässä on taulukkoni rakenne xml-tiedostosta, joka poimitaan jokaiseen viestiin (lukuunottamatta tuota ympäröivää "containerin" korviketta).
<vieraskirja> <viesti> <kirjoittaja></kirjoittaja> <pvm></pvm> <teema></teema> <data smallImage=""></data> <vastaus></vastaus> <url></url> <addr></addr> </viesti> </vieraskirja>
Kuten huomaat, siihen on myös lisätty atribuutti data-tagiin. Ja vaikka en olisi tuota siihen lisännytkään, en olisi ruvennut sen takia muokkaamaan ja "rikkomaan" ParseXml-luokkaa.
Tämän ParseXml-luokan olen netistä löytänyt ja olen sitä muokannut sen verran, että sille voi xml-tiedostonimen sijasta syöttää myös pelkkää xml-dataa.
Metabolix kirjoitti:
Optimitilanteessa jopa salasanojen suolaus on tarpeetonta, mutta toki niiden kohdalla on perusteltua noudattaa tiettyä varovaisuutta.
Offtopic... mutta mitä on salasanojen suolaus?
Helpottais varmaan huomattavasti kertoa myös tässä keskustelussa, että olet tekemässä foorumisoftaa niille, joilla ei ole käytettävissään tietokantaa (tai PHP 5).
Macro kirjoitti:
onkohan taulukoissa jokin pahempikin suunnitteluvirhe?
Huomaa, että taulukko luetaan XML-metodeilla, ts. nollaindeksit ovat siellä tallennusformaatin takia.
pistemies kirjoitti:
Lebe80: En salaa koko tiedostoa, vain xml-tagien välissä olevan datan
Eiköhän Lebe80 kyseenalaistanut juurikin tämän. Komppaan kaikkia, salaa pelkästään ne tiedot, jotka eivät muutenkaan näy muille käyttäjille, kuten salasana ja mahdollisesti se sähköpostiosoite (näitähän niissä viime aikojen tietomurroissa sitten leviteltiin). Salasanasta kannattaa joko laskea tiiviste, tai sisällyttää salasana osaksi salausavainta, jotta kukaan muu kuin käyttäjä itse ei pääse salasanaan käsiksi vaikka joku pääsisikin lukemaan tietokantaa vapaasti.
Kaiken datan salauksella ei saavuteta lisäturvaa, kun tiedot ovat kuitenkin saatavilla sivuston käyttöliittymän kautta. Salaus vie palvelimelta resursseja niin tilan (sekä kryptaus että base64-muotoon muuttaminen lisäävät tekstin pituutta melkoisesti) kuin prosessoinninkin osalta. Veikkaisin, että lisäresurssivaatimukset saattavat jopa tuottaa softassasi oikeita ongelmia. Kaiken tämän lisäksi käytät erittäin verboosia tallennusmuotoa.
ZeroGravity kirjoitti:
mitä on salasanojen suolaus?
Merkkijonon lisäys salasanaan ennen siitä tiivisteen laskemista tai sen kryptaamista, auttaa ennalta laskettuja sateenkaaritauluja vastaan. Kts. seuraavat
tsuriga kirjoitti:
ZeroGravity kirjoitti:
mitä on salasanojen suolaus?
Merkkijonon lisäys salasanaan ennen siitä tiivisteen laskemista tai sen kryptaamista, auttaa ennalta laskettuja sateenkaaritauluja vastaan brute-force hyökkäyksissä.
Niin kyllähän minä tiivisteen laskemisen ja siihen suolan lisäämisen tiedän ... mutta noh... ei mitään :)
Ei sitä suolaa siihen tiivisteeseen lisätä (tai miksei sen nyt siihenkin voi laittaa), vaan kuten Metabolix sanoi, salasanaan. Englanniksi taidetaan sanoa salted password.
pistemies: miksi sitten tiedostomuoto xml? Mikset samalla serialisoinut taulukkodataa?
Lebe80 kirjoitti:
pistemies: miksi sitten tiedostomuoto xml? Mikset samalla serialisoinut taulukkodataa?
Ihan tuon homman helppouden vuoksi tuli idea laittaa xml-hommana, kun on valmis luokka. Ja olihan siinä jotain motivaatiota tehdä sellaista mitä en ennen ollut ennen vielä tehnyt. Nimittäin käyttää xml-tiedostoja tällä tavoin.
Tarkoititko serialize-funktion käyttöä vai jotain "omaa systeemiä"?
Ehkä noille txt-tiedostoillekin voisi kehittää jonkin näppärän ParseTxt luokan skriptejä yksinkertaistamaan :)
pistemies kirjoitti:
Ihan tuon homman helppouden vuoksi tuli idea laittaa xml-hommana, kun on valmis luokka.
Eikö se serialize-funktio ole tuhannesti helpompi?
Metabolix kirjoitti:
Eikö se serialize-funktio ole tuhannesti helpompi?
En nyt ihan noin kauhean suurta eroa näille tekisi. Tutkin hiukan tuota serialisointia, on se tietysti jonkin verran "helpompaa".
Mutta ei tämä xml-juttukaan niin kamala ole. Ehkä siinä voisi tulla haasteeksi, miten muuttaa php:n xml-array takaisin xml-dataksi, kun tiedostoa muokataan. Olen sitä asiaa helpottanut sen verran, että se onnistuu näin lyhyellä skriptillä:
<?php $xml_data = $xml->Back($array); ?>
Tuota ennen arrayhyn tehdään normaalit päivitykset uuden viestin (vieraskirjassa viestit on samassa tiedostossa, foorumissa data kootaan eri tiedostoista) tai adminin muokkauksen seurauksena.
XML:n etuja ovat toki se, että foorumi voidaan tarvittaessa renderöidä suoraan halutun näköiseksi helposti CSS:ää tai XSL:ää käyttäen, sekä se, että data kuvaa itse sisältönsä, ts. on semanttista.
tsuriga kirjoitti:
XML:n etuja ovat toki se, että foorumi voidaan tarvittaessa renderöidä suoraan halutun näköiseksi helposti CSS:ää tai XSL:ää käyttäen
Tuo nyt on hyvin teoreettinen etu, jos koko foorumin kaikki tuhannet viestit on tungettu yhteen tiedostoon.
tsuriga kirjoitti:
sekä se, että data kuvaa itse sisältönsä, ts. on semanttista.
Melkeinpä mikä tahansa taulukko ajaa tässä saman asian, kun data koostuu yksinkertaisista, keskenään samanlaisista tietueista.
pistemies kirjoitti:
En nyt ihan noin kauhean suurta eroa näille tekisi. – – Olen sitä asiaa helpottanut – –
Tietenkin XML-luokkaa on kohtalaisen helppo käyttää sitten, kun siihen on tehty tarvittavat apufunktiot, mutta valmiilla serialize- ja unserialize-funktioilla olisi säästynyt sekin aika ja vaiva. Lisäksi valmiit funktiot luultavasti toimivat nopeammin ja varmemmin, ja PHP:n puolella dataa on helpompi käyttää, kun päästään tuohon Macron esittämään rakenteeseen.
Metabolix kirjoitti:
Tuo nyt on hyvin teoreettinen etu, jos koko foorumin kaikki tuhannet viestit on tungettu yhteen tiedostoon.
pistemies kirjoitti:
foorumissa data kootaan eri tiedostoista
Metabolix kirjoitti:
Melkeinpä mikä tahansa taulukko ajaa tässä saman asian, kun data koostuu yksinkertaisista, keskenään samanlaisista tietueista.
Silloin kun tietueilla on myös selkokieliset avaimet, ts. tieto on indeksoitua, niin kyllä. Puhuin XML:n eduista yleisellä tasolla, ja mikäli kävisikin, että tietoa halutaan siirtää toiseen ohjelmaan, XML on useissa kielissä suoraan tuettu formaatti. XML:llä saavutetaan myös monia muita etuja dokumentoinnin ja validoinnin saralla, joista muistelisin taannoin johonkin keskusteluun kirjoittaneeni.
Yksin PHP:n puolella – eritoten jos lähdetään kikkailemaan kryptauksien ja base64-koodauksien kanssa – on toki nopeampaa käyttää yksinkertaistettua muotoa datan tallennukseen. Toteutuksen mielekkyys riippuu siitä, muistaako tosiaan dokumentoida tuotokset.
En nyt siis sano, että XML olisi tässä paras ratkaisu, mutta ei se nyt ihan huonokaan välttämättä ole.
Metabolix kirjoitti:
Tietenkin XML-luokkaa on kohtalaisen helppo käyttää sitten, kun siihen on tehty tarvittavat apufunktiot, mutta valmiilla serialize- ja unserialize-funktioilla olisi säästynyt sekin aika ja vaiva.
Empä usko, että se aika ja vaiva, mikä tuohon on mennyt, on niin suuri, ettei siihen voi aikaa käyttää. Varsinkin, kun siitä jatkossa on hyötyä kaikissa muissakin tapauksissa, kun jotakin xml-tiedostoa tarvitsee php:lla muokata.
Sen verran tein muutoksia, että yhdistin nuo tekemäni xml-back metodin ParseXml-luokkaan (aiemmin se oli oma luokkansa) niin helpottaa taas "hiukan" lisää.
Ps. Taidan jossakin vaiheessa lisätä siihen vielä jonkin XmlForm-metodin, johon "automaattisesti" tulostetaan avatun xml-tiedoston muutos-lomake. Se ei tietenkään ole kovin käytänöllinen hyvin suurille xml-tiedostoille mutta "normaali"-tiedostoilla siitäkin on hyötyä.
Metabolix kirjoitti:
jos koko foorumin kaikki tuhannet viestit on tungettu yhteen tiedostoon.
Kiitos ajatuksesta. Tuosta sain yhden idean.
Vaikka minulla meneekin foorumissa kaikki eri tiedostoihin, niin tähän kannattaa soveltaa samaa periaatetta kuin tulostettaessa mysql-tietokannasta.
Ei kannata turhan takia php-arrayn, josta tulostetaan sivulle, olla mahdottoman pitkä. Eli suunnittelen tähän sellaista systeemiä, että kun on kyse keskustelu-ketjun otsikko-listasta, niin php-arrayhyn poimitaan vain ne otsikot, jotka tulostetaan yhdellä sivulla (esim. 25 kpl).
Tällä hetellä minulla on siten, että poimitaan arrayhyn tiedostonimet ja yhdistetään kaikkien tiedostojen data. Siihen suunnittelen systeemiä, joka poimii vain niiden tiedostojen datan, jotka sijaitsee tietyssä kohtaa tuota tiedotonimi-arrayta, esim. sivu 1 poimisi tulostettavaksi tiedostot arvoista 0-24, sivu 2 arvoista 25-49 jne.
Aihe on jo aika vanha, joten et voi enää vastata siihen.