Keskustelu: Nettisivujen teko: PHP: Onko turvallista tallentaa salasana sessioon?

Hei,

Minulla on sivustoja, ja olen niille salasana toimintaa miettimässä, pelaajien salasana olisi tarkoitus antaa https:// kautta, etusivu.html kanssa.

Salasanaa pitäisi kuitenkin kyetä käyttämään, myös latautuvan http:// AOv5.00+ kanssa.

Mietin, että, käytän php sessio toimintaa, eli, tämä https:// sivu syöttää salasanan ja käyttäjätunnuksen selaimeen ja sitten myös php sessioon.

Voiko käyttäjät sitten turvallisesti käyttää salasanaa ja käyttäjätunnusta esim. näin -

https:// etusivu.html kysyy salasanan ja käyttäjätunnuksen, ja tallentaa ne selaimeen ja php sessioon.
https:// etusivu.html sisältää lataa buttonin joka lataa http:// asiakasohjelma.html fileen.
http:// asiakasohjelma.html file sisältää php koodia joka tarkistaa serverissä sessio salasanan ja käyttäjätunnuksen, jos molemmat on ok, niin, sama asiakasohjelma.html lataa sitten myös itse http:// AOv5.00+ ohjelman ja pelejä voi pelata, jos session salasana ja käyttäjätunnus ei ole databasessa, AOv5.00+ ei käynnisty ollenkaan.

Toimiiko noin, ihan oikein, vai onko turvallisuus vajeita ?

Minä en laita tätä https:// toimintaa proxyn kautta, tähän ekaan AO versiooni, en halua että google sanoo turvallinen, tämä on minun eka iso js ohjelma ja noloja ohjelmointi / graafisuus virheitä jotka haittaavat käyttäjää voi löytyä ainakin alkuun, korjaan ne kyllä ajan kanssa. :)

:)

--

Itse en laittaisi suoraan salasanaa siirtymään mihinkään, vaan käyttäisin suolausta (salt). Tässä esimerkkiä: http://www.jotlab.com/2010/cakephp-rainbow-table-protection-behaviour

Salasana kannattaa tarkastaa heti. Salasanan tallentaminen istuntoon olisi samanlainen tietoturvariski kuin ylipäänsä salasanan tallentaminen selkokielisenä palvelimelle. Lisäksi, jos salasana kysytään sivulla A ja tarkastetaan sivulla B, tulee vaikeammaksi kysyä salasanaa uudestaan, jos se oli väärin. Siksi kannattaa hoitaa ensin salasanan kysyminen ja tarkastaminen (ja tarvittaessa uusi yritys) ja vasta oikean salasanan jälkeen ohjata käyttäjä seuraavalle sivulle. Siinä vaiheessa ei pidä säilyttää enää salasanaa, vaan jatko voi tapahtua istunnolla. Istunnon tunnus on yleensä satunnainen ja käytössä vain yhden istunnon ajan, ja siksi se on turvallisempi kuin käyttäjän salasana.

HannuTapio kirjoitti:

https:// ... http://

Miksi käytät molempia muotoja? Kannattaa käyttää kaikkeen salattua yhteyttä. HTTP:n käyttö on ihan samalla tavalla vaarallista myöhemmin kuin alkuvaiheessakin: vaikka salasanaa ei voi silloin enää vakoilla, istunnon tunnuksen tai muita tietoja voi vakoilla, tai pahimmassa tapauksessa käyttäjälle voi syöttää väärennetyn version ohjelmasta (esim. vasta julkaistun WLAN-verkkojen KRACK-hyökkäyksen avulla). Lisäksi HTTPS-yhteys mahdollistaa uuden HTTP/2-protokollan käytön, joka voi säästää nettiliikennettä.

MtJ kirjoitti:

Itse en laittaisi suoraan salasanaa siirtymään mihinkään, vaan käyttäisin suolausta (salt).

Selitätkö vielä, miten suolaus ja salasanan siirtäminen liittyvät toisiinsa? Yleensä suolaus liittyy salasanan tiivistämiseen ja tiivisteen tallentamiseen, ja tämä ei ole mitään tekemistä sen kanssa, missä muodossa salasana siirretään käyttäjältä palvelimelle.

Salasana ja php sessio,

Minä teen näin -

1)
Sivustoille kirjautuminen https:// Etusivu.html kanssa.

2)
Tämä https:// Etusivu.html tarkistaa salasanan ja käyttäjätunnuksen, jos ok, niin, tallentaa sessioon pelaaja nimen, jos ei ok, niin, tämä pelaaja nimi on defaulttina "Vieras".

3)
Sitten kun lataa http:// asiakasohjelman kanssa, niin, asiakasohjelma.html ja php lataa tämän pelaajanimen sessiosta, ja tallentaa pelaaja nimen javascriptiin echon avulla.

---------------

Tuo on simppeli ja hyvä keino, uskon niin.

Eli, pidän pelaaja nimen sessiossa defaulttina "Vieras", ja sitten kun on onnistunut pelaaja kirjautuminen, niin, php vaihtaa sessioon pelaaja nimen käyttäjätunnukseen.

Näin menee hienosti.

:)

--

Mitäs jos pelaajan nimi on "Vieras"?

HannuTapio kirjoitti:

Sitten kun lataa http:// asiakasohjelman kanssa, niin, asiakasohjelma.html ja php lataa tämän pelaajanimen sessiosta, ja tallentaa pelaaja nimen javascriptiin echon avulla.

Tuo on simppeli ja hyvä keino, uskon niin.

Ei ole! Lähetät silloin istunnon tunnuksen ilman salausta HTTP:llä, ja hakkeri voi vakoilla sen ja varastaa käyttäjän istunnon.

Älä käytä HTTP:tä, jos pystyt käyttämään HTTPS:ää!

HTTP vai HTTPS,

Minulla ei ole tällä hetkellä oman tietämykseni mukaan mahdollista käyttää https:// taikka wss:// yhteyttä asiakasohjelman kanssa.

Minulla on server ohjelmani tuolla serversocketilla, minulla ei ole glassfish, taikka muuta vastaavaa, tuo wss:// handshake taitaa olla erillainen, mitä minä olen käsin kirjanna omaan java .net serversocket palvelinohjelmaani.

Mutta, minä varmuuden vuoksi vielä testaan myöhemmin, sitä nginx ja proxy neuvoa, minkä sain aiemmin, mutta, siinäkin on sitten tämä lause, että, tämä letsencrypt taitaa olla ennemminkin hypertext ja javascript sivuille, kuin varsinaisesti peli sivuston peli pakettien salaamiseen.

Minä vähän karsastan tätä nginx ja proxy, koska letsencrypt on tarkoitetty ihan http salaukseen, eikä pelien pakettien.

:)

Minulla AsiakasOhjelma v5.00+ on tarkoitettu vain live pelien käyttöön, minulla on mietteissä myös, että, kysyn vain nimen joka kerta AOv5.00+ käynnistyessä, ja sitten julkinen peli nimi, jonka kaikki näkee, eikä rekisteröintiä ollenkaan.

Mitä tarkoittaa varastaa käyttäjän istunnon, minulla ei ole mitään salaista pelaajan tietoa AOv5.00+ kanssa, vain pelaajan nimi on AOv5.00+ kanssa, ei tallenteita ei mitään videoita, ei muuta kuin se julkinen pelaaja nimi ??

Olen lautapeli harrastelija, en ole ohjelmoija, mikä on istunnon tunnus ?

--

Mitään "peli paketteja" ei ole olemassakaan.

Peli paketti,

WebSocket käsittää TCP siirrossa, headerin ja dataa, tämä muodostaa yhdessä "pelin TCP paketin".

WebSocket jaksottaa TCP siirron, aina header + data, ja sitten sama alusta, nämä siirrot ovat "pelin paketteja", joissa sitten data liikkuu halutusti.

Mutta, olen silti yhä vain lautapeli harrastelija, millä nimikkeellä kutsutaan, TCP WebSocket header + data ?

Eikö tämä header + data voi olla "peli paketti".

:)

--

Niin ne sun "peli paketit" on ihan normaalia websocket liikennettä, ja siinä on mahdollista kyllä käyttää SSL:ää.

SSL,

Onko mahdollista käyttää SSL:ää, vaikka minulla on palvelinohjelma, joka on Java SE .net ja ServerSocket.

Minulla ei ole json taikka mitään glassfish, taikka mitään muutakaan vastaavaa.

Vain ihan perus Java SE .net ServerSocket.

Minä en ole tähän kysymykseen saanut selkeätä vastausta vielä ! :)

Jos on niin, voin katsella sitä hieman myöhemmin sitten vaikka, laitan ensin nämä tabletpelisivuston pelit, ja vielä multipelaajan menutkin linjalle. :)

SSL, tarkoittaa sitten ilmeisesti NGINX ja PROXY, taikka se APACHE TUNNEL MOD ja PROXY ??

Katselleen sitä sitten myöhemmin, tämä oli php ja sessio ketju, otan uuden ketjun sitten myöhemmin.

??

--

HannuTapio kirjoitti:

Olen lautapeli harrastelija, en ole ohjelmoija, mikä on istunnon tunnus ?

Se on HTTP-pyynnön mukana siirtyvä tieto, jonka perusteella palvelin tunnistaa, mikä istunto (session) kuuluu millekin käyttäjälle (client, user). Yleensä se siirtyy evästeenä (cookie) mutta joskus myös osoitteessa GET-parametrina.

Kun PHP:ssä aloitetaan istunto funktiolla session_start, tapahtuu suunnilleen seuraavaa: PHP tarkastaa, onko käyttäjältä tullut eväste PHPSESSID. Jos eväste on, PHP avaa sen mukaisen istunnon. Jos evästettä ei ole, PHP avaa uuden istunnon ja asettaa kyseiseen evästeeseen istunnon tunnuksen (session id).

HannuTapio kirjoitti:

Onko mahdollista käyttää SSL:ää, vaikka minulla on palvelinohjelma, joka on Java SE .net ja ServerSocket.

SSL-yhteyttä varten tarvitaan SSLServerSocket, joka kyllä luomisen jälkeen toimii melko samalla tavalla kuin ServerSocket. Netissä on esimerkkejä.

Esimerkkejä,

Löysin näin simppelin esimerkin javax.net.ssl.serversocket

package main;

import java.io.InputStream;
import java.io.OutputStream;
import java.net.ServerSocket;
import java.net.Socket;

import javax.net.ServerSocketFactory;
import javax.net.ssl.SSLServerSocketFactory;

public class sslsocket
{
	public static void main ( String [ ] argv ) throws Exception
	{
		int port = 443;
		ServerSocketFactory ssocketFactory = SSLServerSocketFactory.getDefault ( );
		ServerSocket ssocket = null;
		try
		{
			ssocket = ssocketFactory.createServerSocket ( port );

		} catch ( Exception e )
		{
			e.printStackTrace ( );
		}
		Socket socket = ssocket.accept ( );
		InputStream in = socket.getInputStream ( );
		OutputStream out = socket.getOutputStream ( );

		// Read from in and write to out...

		in.close ( );
		out.close ( );
	}
}

Tuo palauttaa cant bind to address ??

Miksi ei toiminut noilla asetuksilla, mitä pitää lisätä.

--

Jos palvelimella on jo HTTPS-palvelin, et tietenkään voi kuunnella samassa portissa vielä Javalla. (Tai jos testaat koodia muualla kuin palvelimella, muista, että porttien 1–1024 käyttämiseen tarvitsee Linuxissa root-tunnuksen tai muuten vastaavat lisäoikeudet.) Eli aseta koodissa portti oikein.

Ok,

Kiitos, minulla on nyt tuon ylläolevan koodin mukaan rakennettu ssl accept koodi palvelimessa.

Minulla on palvelimessa javax.net.ssl.* sslserversocket kuuntelemassa portteja :8080 - :8085.

Minulla on websocket koodi, ottamassa wss:// yhteyttä satunnaisesti portteihin :8080 - :8085.

Tämä connect tapahtuu aina oikein, nyt sitten google chromen mukaan, virheilmoitus on seuraavanlainen -

"tcp handshake timed out".

Kuinka tuo handshake tule rakentaa https:// ja wss:// yhteyksissä.

??

Oliko tämä se hetki kun tarvitsee sitten sen java sertifikaatin ? Voiko rakentaa omaa sertifikaattia ssl varten ?? keytool taikka jokin vastaava ?

--

Sertifikaatti hommataan esimerkiksi Let's encryptiä käyttäen. Täysin omavaraisissa serteissä ei ole mitään järkeä, koska yhtä hyvin voisit olla käyttämättä https:ää.

Java,

Minä Java puolen sertifikaattia mietin, palvelinohjelmaani, minullahan jo on tuo Let's encrypt palvelimessani. :)

--

No tietysti käytät sitä samaa "Javan puolella"kin.

Let's Encryptin PEM-muotoiset tiedostot (privkey.pem ja fullchain.pem) täytyy muuttaa Javan ymmärtämään muotoon, esimerkiksi PKCS12-muotoon. Muunnoksessa tiedot myös salataan salasanalla. Muunnos tapahtuu OpenSSL:llä seuraavasti:

openssl pkcs12 -export -inkey privkey.pem -in fullchain.pem -out java-keystore.pfx

Sertifikaatti ja avain täytyy sitten avata Javassa, jotta SSL-palvelin toimisi:

import java.util.*;
import java.io.*;
import java.net.*;
import java.security.*;
import javax.net.*;
import javax.net.ssl.*;

// openssl pkcs12 -export -inkey privkey.pem -in fullchain.pem -out java-keystore.pfx

public class SSLServer {
	public static ServerSocket listenSSL(int port, String keyStore, String keyStorePassword) throws Exception {
		char[] pass = keyStorePassword.toCharArray();
		KeyStore ks = KeyStore.getInstance("PKCS12");
		ks.load(new FileInputStream(keyStore), pass);
		KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
		kmf.init(ks, pass);
		SSLContext ctx = SSLContext.getInstance("TLS");
		ctx.init(kmf.getKeyManagers(), null, new SecureRandom());
		return ctx.getServerSocketFactory().createServerSocket(port);
	}
	public static void main(String[] args) throws Exception {
		ServerSocket ss = listenSSL(8080, "java-keystore.pfx", "kissa2");
		for (int i = 1;; ++i) {
			Socket s = ss.accept();
			PrintWriter output = new PrintWriter(s.getOutputStream());
			output.format("i=%d, 'exit' sulkee palvelimen\n", i).flush();
			Scanner input = new Scanner(s.getInputStream());
			String command = input.hasNext() ? input.next() : null;
			s.close();
			if ("exit".equals(command)) {
				break;
			}
		}
		ss.close();
	}
}

Toinen vaihtoehto edelleenkin on käyttää HTTPS-palvelimen proxy-ominaisuutta, jolloin ei tarvitse Javassa huomioida SSL:ää ollenkaan.