Perche' non adottare tout-court https ?

[Janvitus]

cercando dicono che phpbb 3.1, correntemente in RC, dovrebbe supportare nativamente openid.

Alla RC2 supporta solo l'accesso tramite Facebook, Google e Bit.ly, ma solo l'accesso, niente creazione nuovo utente. Fino alla stabile forse implementano gli openid e la creazione degli utenti.

[harrykar]

Dopo aver parlato con alcuni amici nel ambiente perché' più aggiornati di me ho ottenuto diverse risposte e facendo l' intersezione si ottiene che attualmente c'e' almeno una CA(in passato c' erano tante ricordo ma allora https era agli inizi, comunque il nome di Startcom me l' hanno consigliato 5 persone su 6) Startcom che:

1. emette aggrattisse certificati validi --nel senso che non avrebbero problemi con i famigerati e tanto temuti --dalla gente comune-- warnings da parte del browser --@Wilson non c'e' niente di male anzi e' piu che positivo questo warning il vero problema sta altrove stesso dicasi con gli alert del anti-malware nel mondo a fineste;-- perché altrimenti si potrebbe aggiungere anche CAcert.org a riguardo di quest' ultima guarda PS -- free Class1.

2. Si pagherebbe solo un' eventuale revoca(*).

3. La validità del certificato e' per 1 anno e si rinnova anno dopo anno;

ma siccome non c'era tempo che per una menzione dovrei parlare meglio con i miei amici prima di riferire qui (* appunto in primis sulla --come mi si e' lasciato capire -- cara paga in caso di revoca del certificato + qualsiasi altra cosa connessa riguardante questo tipo di cert. Posso solo anticipare con assoluta certezza che questo cert (free) tecnicamente non ha niente da invidiare dai suoi fratelli a pagamento)

<edit> 6/8/14
Qui metto altre CA che di volta in volta arrivano al mio orecchio -- in prima approssimazione, una specie ti note ovvio che si dovrebbe dissezionare ai minimi particolari ogni proposta; ognuno impieghi le sue fonti (meglio se operanti nell' ambiente l' esperienza paga sempre meglio e più veloce che poche aride righe -- in caso si possano scorgere senza lenti di ingrandimento --) --
a. Appena ho saputo circa i Free wildcard SSL Certificates for Open Source Projects da Globalsign
b. Riporto qui anche le altre CA's che m' avevano menzionato precedentemente oltre alla Startcom Comodo;
b1. Freessl , RapidSSL
c. Thawte
<edit/>


PS:
1. Ho voluto riferire anticipatamente questa notizia per dare un respiro di sollievo ai probabili pessimisti

2. Riguardo CAcert.org debbo dire che la conosco da moltissimo credo forse dalla sua nascita da quando ai miei anni verdi mi occupavo anche di gestione siti e so per certo molti amici che hanno adottato un suo certificato senza nessun problema ai tempi che furono(ne e' passato del tempo non mi meraviglio perché non mi e' venuta in mente già al primo post).

Per saggiare il comportamento attuale si faccia qualche click a un piccolo campionario di siti che --probabilmente-- hanno adottato un loro certificato (non ho avuto tempo di farlo da me)


Cheers, (grazie @WebbyIT a big hug to you Ceers ha un piccolo aneddoto indietro che racconterò al prox post )
Harry G. T. Kar

[kimj]

ma i certificati startcom sono wildcard? sarebbe altrimenti impossibile mettere sotto https tutto ubuntu-it come richiesto da questo topic

[harrykar]

Gianvito potresti controllare da qui se ubuntu-it soddisfa le loro richieste? e in caso di si riempire la form?

Qui verso fine riporta che sono wildcard(sarebbe ottimo credo):
GlobalSign also offers free wildcard certificates for Open Source projects (for as long as the project is active).

PS:
mp non funziona per te?

[Janvitus]

Gianvito potresti controllare da qui se ubuntu-it soddisfa le loro richieste? e in caso di si riempire la form?

Non sono lo Shuttleworth di ubuntu-it, posso solo decidere per il forum.

Qui verso fine riporta che sono wildcard(sarebbe ottimo credo):
GlobalSign also offers free wildcard certificates for Open Source projects (for as long as the project is active).

PS:
mp non funziona per te?

A proposito di forum, avevo già scritto che se si voleva discutere di esclusivamente del forum si doveva cambiare posto e usare la sezione Gruppo Forum

[Barrnet]

la cosa piu' sensibile e' la password degli utenti, che spesso e' considerata piu' privata dei dati che protegge (per il ragionamento dietro e per l'uso su piu' servizi).

visto che https costa troppo e non si puo' fare in modo che phpbb hashi la password (il problema salta fuori solo ora perche' smf non inviava in chiaro), che ne dite della proposta di supportare openid per gli utenti paranoici? alla fine non sono l'unico ad aver sollevato il problema, richiede 'solo' una mod, credo, ed ha anche altri benefici, anche ubuntuforums.org lo usa

phpBB, pur usando ancora l'obsoleto md5, hasha già le password con un salt diverso per ogni sessione, in pratica l'hash memorizzato cambia ad ogni login :3

[kimj]

la cosa piu' sensibile e' la password degli utenti, che spesso e' considerata piu' privata dei dati che protegge (per il ragionamento dietro e per l'uso su piu' servizi).

visto che https costa troppo e non si puo' fare in modo che phpbb hashi la password (il problema salta fuori solo ora perche' smf non inviava in chiaro), che ne dite della proposta di supportare openid per gli utenti paranoici? alla fine non sono l'unico ad aver sollevato il problema, richiede 'solo' una mod, credo, ed ha anche altri benefici, anche ubuntuforums.org lo usa

phpBB, pur usando ancora l'obsoleto md5, hasha già le password con un salt diverso per ogni sessione, in pratica l'hash memorizzato cambia ad ogni login :3

bene, peccato che lo fa sul server, non in js sul client, e la password viene trasmessa in chiaro. il che non e' bene.
se la password hashata, ma solo sul db del server, serve ad evitare che compromesso questo si ottengano le password di tutti gli utenti, beh, non ci vuole molto, una volta compromesso, a loggare le password o sniffare il traffico.

vedo come piu' probabile che le password siano raccolte in massa dagli utenti, per esempio quando usano wifi pubbliche, che l'eventualita' che i server canonical vengano bucati nuovamente da novizi tali che si limitano a copiare il db con le password md5

[Barrnet]

Se si salva la password in locale è vulnerabile ad eventuali malware o infiltrazioni dirette, e li cosa cambierebbe rispetto ad un attacco man in the middle?
Non capisco poi a cosa ti riferisci con "la password è inviata in chiaro", perché anche SMF invia la password via protocollo http, salvo non sia configurato un protocollo sicuro: che cambia rispetto a phpBB?

Ad ogni modo penso che sia la base della sicurezza non effettuare login importanti da reti wifi non protette

[kimj]

Se si salva la password in locale è vulnerabile ad eventuali malware o infiltrazioni dirette, e li cosa cambierebbe rispetto ad un attacco man in the middle?
Non capisco poi a cosa ti riferisci con "la password è inviata in chiaro", perché anche SMF invia la password via protocollo http, salvo non sia configurato un protocollo sicuro: che cambia rispetto a phpBB?

Ad ogni modo penso che sia la base della sicurezza non effettuare login importanti da reti wifi non protette

smf la invia si' via http, ma il client non invia la password in chiaro, bensi' un hash della password, il salt e l'id di sessione (quindi invia un hash univoco per ogni login non riutilizzabile in replay attack).

certo, se arrivi a fare un attacco attivo capace di iniettare js malevolo sulla pagina per fare da 'keylogger' od inviare semplicemente la password 'onsubmit' anche a te prima che venga calcolato l'hash, non ti salva (servirebbe anche https), ma e' certo meglio che inviarla in chiaro.

ricordo inoltre che esistono 'programmi' atti a raccogliere in massa login di milioni di persone, associare le varie identita' virtuali con quella fisica ed associarvi le password. questo e' certamente piu' facile quando questa viene inviata in chiaro, non si tratta solo di wifi pubbliche.

[Barrnet]

SMF non è più sicuro di phpBB: considera che al posto di usare un salt che cambia randomicamente ad ogni login usa il nome utente, convertito in lowercase, come salt per la password in SHA1.
phpBB usarà pure l'oramai obsoleto MD5 (credo per questioni di compatibilità: cambiare il sistema di memorizzazione delle password costringerebbe l'intera utenza a cambiare password) ma utilizza un salt preso randomicamente attraverso il dispositivo "virtuale" urandom di linux (se presente) e altri passaggi:

Codice: Seleziona tutto

function phpbb_hash($password)
{
	$itoa64 = './0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz';

	$random_state = unique_id();
	$random = '';
	$count = 6;

	if (($fh = @fopen('/dev/urandom', 'rb')))
	{
		$random = fread($fh, $count);
		fclose($fh);
	}

	if (strlen($random) < $count)
	{
		$random = '';

		for ($i = 0; $i < $count; $i += 16)
		{
			$random_state = md5(unique_id() . $random_state);
			$random .= pack('H*', md5($random_state));
		}
		$random = substr($random, 0, $count);
	}

	$hash = _hash_crypt_private($password, _hash_gensalt_private($random, $itoa64), $itoa64);

	if (strlen($hash) == 34)
	{
		return $hash;
	}

	return md5($password);
}

[kimj]

guarda e' passato del tempo da quando ho visto SMF, ma non mi pare usi l'id utente come salt, mi pare di ricordare chiaramente che usi un id di sessione nell'hashare la password al login sul client per evitare replay attack.

se non erro, ma qui potrei ricordare male, combinava nell'hash anche un qualche salt. probabilmente era l'id utente, ma questo non vieta di usare poi anche un vero e proprio salt sul server quando si salva la password nel database:
usare un salt debole per hashare una password, poi hasharla ancora con un id sessione in modo da rendere tale hash unico per ogni login, e poi solo sul server usare un salt proprio e' comunque piu' sicuro che trasmetterla in chiaro ed usare un salt proprio nell'hasharla lato server

ma non e' un po' offtopic?