Tag: security

Posted on

Old news, but news to me: WordPress security key definitions in wp-config.php

While investigating an entirely separate issue with one of my WordPress installations, I came across this:

“Beginning with WordPress Version 2.6, three (3) security keys, AUTH_KEY, SECURE_AUTH_KEY, and LOGGED_IN_KEY, are used to insure better encryption of information stored in the user’s cookies. Beginning with Version 2.7 a fourth key, NONCE_KEY, was added to this group.

If you don’t find the keys in your wp-config.php file, add the keys definitions with reference to Editing wp-config.php – Security Keys, and upload to your server.”

Step 13: Add security key definitions to the wp-config.php file
WP Codex

Since most of my WordPress installations are pretty ancient, and upgrading them has long since become a routine job, this was the first time I heard about this feature. So my blogs have been lacking in this security feature, until now (I set up the aforementioned keys in each of my wp-config.php files).

Posted on

WordPress-blogi ja HTTPS

Periaatteessa WordPressin hallinnan voi sujauttaa SSL:n alle suhteellisen yksinkertaisesti. Ongelmalliseksi se muodostuu siinä tapauksessa, että maailmalle näkyvään osoitteeseen ei liity varmennetta. Esimerkiksi mummila.netillä ei ole omaa varmennetta, koska sellaisen hankkiminen on melko kallista.

Www-hotellina käyttämäni Kapsin palvelimella on varmenne, ja niinpä https-yhteydet mummila.kapsi.fi-osoitteeseen (jonka http-sisältöä mummila.net tosiasiassa vain heijastelee) ovat mahdollisia. Valitettavasti WordPressin hallinta ei kuitenkaan taivu kovin sujuvasti SSL:n alle siten, että blogi näkyisi ulkomaailmalle yhden palvelimen (omassa tapauksessani mummila.net) alla, ja hallintayhteyksiin taas käytettäisiin toista palvelinta (mummila.kapsi.fi).

Kaikkein ongelmallisin kohta on kommentointi. Tuollainen kaksisuuntainen viritelmäkin olisi vielä kohtalaisen helppo toteuttaa, jos kommentointia ei olisi: kaiken hallintoliikenteen voi .htaccessin ja WordPressin URL-asetuksen avulla pakottaa https:n alle, ja kaikki muu näkyy maailmalle edelleen oman domainin eli blogin URL:n alla tavallisessa http-yhteydessä. Mutta jos tuon WordPressin URL:n asettaa osoittamaan https-yhteyden sallivalle palvelimelle, joka on eri kuin millä blogin sisältö näytetään, kommenttien yhteydessä käytetyt evästeet eivät tietenkään toimi, koska niitä ei pysty asettamaan palvelinten kesken ristiin.

Kun evästeiden asettaminen ei toimi, kommentoijalle normaalisti näkyviä ilmoituksia kommentin päätymisestä moderointiin ei näytetä. Niinpä kommentoijasta vaikuttaa siltä kuin onnistuneesti jätetyt kommentit katoaisivat mustaan aukkoon, vaikka tosiasiassa ne ovatkin vain moderoinnissa. Lisäksi sisäänkirjautuneena oleminen ei näy kommenttilomakkeessa, vaan se kysyy myös ylläpitäjältä osoitetietoja. Jälkimmäisen ongelman takia minun täytyy pitää turvatonkin kirjautumismahdollisuus käytössä, koska muutoin en pystyisi kommentoimaan omaa blogiani virallisella blogi-isännän identiteetilläni.

Käytännössä siis salattua yhteyttä voi sujuvasti käyttää vain täällä blogin konehuoneen puolella touhutessaan, esimerkiksi uusien merkintöjen luomisessa ja julkaisussa. Onhan sekin nyt tietysti tyhjää parempi, koska julkaiseminen on se kaikkein useimmin sisäänkirjautuneena harrastettu toiminta. Eivätkä ruotsalaiset tietenkään salasanojani saa, kun Kapsin palvelimet ovat kotimaassa. Kotimaisia nuuskijoita tällä lähinnä torjutaan.

Posted on

[Ratkaisu] Nautilus ja tiedostotyyppiin perustuva tietoturvaominaisuus

Lähtökohta
Olen avannut Nautilus-tiedostoselaimeen kansion, joka sisältää header.php -nimisen tiedoston. Valitsen tiedoston hiiren vasenta nappia käyttäen.
Ongelma
Odottamani tiedoston tekstieditorissa avaamisen sijasta Nautilus ilmoittaa seuraavaa:

Ei voi avata: header.php

Tiedostonimi "header.php" ilmaisee, että tiedoston tyyppi on "PHP-komentojonotiedosto". Sisältö kuitenkin ilmaisee, että tyyppi on "HTML-asiakirja". Tämän tiedoston avaaminen saattaa olla turvallisuusriski järjestelmällesi.

Älä avaa tiedostoa, jollet ole joko tehnyt sitä itse tai saanut sitä luotettavasta lähteestä. Tiedoston voi avata nimeämällä se uudestaan ja vaihtamalla tiedostopäätteeksi "HTML-asiakirja", jonka jälkeen sen voi avata normaalisti. Vaihtoehtoisesti, tämän voi tiedä valitsemalla tiedoston avaava sovellus "Avaa sovelluksella"-valikosta.

Ainoa vastausvaihtoehto, jonka ilmoitus valittavakseni tarjoaa, on Peru.

Ongelman syy
.php -päätteinen tiedostoni sisältää HTML-muotoisen asiakirjan, kuten ilmoitus kertoo, ja Nautiluksessa on tietoturvasyistä tällaisten tiedostojen suoran avaamisen esto.
Ratkaisu
Valitsen tiedoston oikealla hiiren napilla ja valitsemalla avautuvasta ponnahdusvalikosta kohdan Avaa ohjelmalla "Tekstieditori".
Huomautus
Eston hyödyllisyydestä ollaan ymmärrettävästi monta mieltä, ja siksi sen poiskytkemiseksi on Nautiluksen nykyisissä versioissa /apps/nautilus/preferences/display_mimetype_warning -avain, jonka arvoa voi muuttaa Sovellukset → Järjestelmätyökalut -valikosta löytyvällä Asetusten muokkaus -sovelluksella. Avaimen pois käytöstä -asentoon asettamisen jälkeen tiedosto avautuu normaalisti vasenta hiirennappia käyttäen.
Posted on

Solved: Ekiga (Ubuntu): Registration Failed: Forbidden (Rekisteröityminen epäonnistui: Estetty)

It looks like they’ve really screwed up the account management over at Ekiga.net: I was allowed to create an ID with a password using special characters, but then the Ekiga client failed to log in with it (giving me the error message I titled this entry with) and I couldn’t even log in at the website.

After requesting my password via e-mail (at the login website) as if I had forgotten it, I got an email not with the password but with a URL which, when clicked, gave me a new password. The new one was a measely five characters long; is that how insecure they expect them to be? Well I changed it to yet another one, still 20 characters long but this time containing only numbers and letters, and it seems to have solved the issue: I’m now able to login with the client.