Wikipedia:Bar/2014 04 10

Il bar di Wikipedia Bar completo Indice della settimana Not Italian? It-0? Go to the Embassy Desk! New message? Deutsch · English · Español · Français  |   Aggiorna la pagina

Cambusa Bar giornaliero 19 aprile · 18 aprile · 17 aprile · 16 aprile · 15 aprile · 14 aprile · 13 aprile Bar delle scorse settimane 5 aprile · 4 aprile · 3 aprile · 2 aprile · 1 aprile · 31 marzo · 30 marzo · 29 marzo · 28 marzo · 27 marzo · 26 marzo · 25 marzo · 24 marzo · 23 marzo Archivio della settimana · Archivio del mese Cambusa · Archivio generale (fino a luglio 2006 e cronologia al 6 lug 2006)

Discussioni in corso Oggi, 19 aprile Nessuna discussione. segui    non seguire    modifiche correlate Aggiungi nuova discussione   Segnala discussione esterna

10 aprile

Cambiate le password!

È bene richiamare piena attenzione su un problema di sicurezza di cui avrete sentito parlare: una grave vulnerabilità di OpenSSL (un software diffusissimo che serve proprio per la sicurezza delle comunicazioni online) mette a rischio gli utenti di due terzi dei siti web, tale essendo la diffusione di OpenSSL.

Anche i siti WMF usano OpenSSL, ma dato che la falla è stata subito sistemata e OpenSSL è tornato in sicurezza, i server Wikimedia sono già stati aggiornati (chi ha la memorizzazione dei dati di accesso avrà notato una inattesa richiesta di nuovo login fra ieri ed oggi). Tuttavia, per un doveroso principio di cautela, WMF invita tutti gli utenti a cambiare il prima possibile le loro password di accesso ai siti Wikimedia.

Potete farlo velocemente da qui e naturalmente è il caso che chi ha flag di amministrazione e superiori lo faccia in tutta velocità. Sarebbe di fatto consigliabile cambiare password per tutti i servizi online, da Gmail a FB, da Twitter a qualsiasi altro sito a rischio. -- g · ℵ (msg) 01:04, 10 apr 2014 (CEST)

Stranamente la mia sessione non è ancora scaduta, eppure i token sono stati resettati ieri. Aggiungerei una piccola precisazione: la lista linkata da Gianfranco si riferisce ai siti effettivamente vulnerabili a mezzogiorno dell'8 aprile, tuttavia

• la falla è stata introdotta nel software più di due anni fa ed è stata scoperta solo da poco (ma c'è il sospetto che sia stata sfruttata già mesi fa)
• la falla è stata sistemata il 6 aprile e annunciata pubblicamente il giorno dopo

per cui quella lista NON riflette i siti che sono stati effettivamente al sicuro (i siti segnati come not vulnerable potevano essere vulnerabili, e quindi potenzialmente compromessi, prima di tale data). In alcuni casi (es. Google) eventuali danni sarebbero limitati (ma non eliminati) grazie all'adozione di ulteriori protocolli di sicurezza, come PFS. Ovviamente ha senso cambiare la password dei propri servizi solo dopo che il proprio fornitore di servizi abbia aggiornato OpenSSL (come prontamente fatto da Wikimedia). --Tino [...] 09:11, 10 apr 2014 (CEST)

_{(conflittato)} Giusto per capire a grandi linee la gravità della vulnerabilità:

Ho letto dal primo link che riguarda l'implementazione dei protocolli SSL/TLS.

Ma aver usato tale implementazione vulnerabile era (ed è, per i siti che non hanno ancora aggiornato) più o meno pericoloso che non usare SSL/TLS (http:// invece di https:// se ho ben capito, giusto?) (al di là dell'aspetto che l'utente era convinto di state usando un metodo sicuro, non era cosciente di usarne non insicuro, anche perché non tutti quelli che usano http:// non sanno della sua insicurezza ... ) --109.55.40.169 (msg) 09:19, 10 apr 2014 (CEST)

@Tino: il fatto, a dirla cruda, è che se qualcuno ha usato la falla per succhiarsi le coppie user/pw prima della scoperta della falla pensando di usarle dopo, ha ancora i dati, perciò la lista che linkato non l'ho messa tanto per listare un problema di falla, quanto per dare l'idea di quali e quanti siti in potenza potrebbe riguardare, su quanti cioè potremmo dover cambiare pw. Indipendentemente dal fatto che i siti abbiano aggiornato OpenSSL, chi avesse preso quelle coppie verosimilmente ce le ha ancora e potrebbe tuttora, per fare un esempio, entrare qui e loggarsi come Utente:Esempio, con tutte le legittimazioni che gli dà l'accesso. Passerà prima dall'online banking, a naso, ma se ha preso dati di qui, li userà qui. Ciò che si sospetta è peraltro che i dati fossero tenuti "in sonno" in attesa di un eventuale attacco di massa (che sarebbe mortale per la Rete).
E' possibile che molti utenti non aggiornino le pw: in genere almeno un 15% (parenti stretti di quelli che hanno per pw 1234) attende che arrivi un deus ex machina che gli sistemi tutto a dovere senza che loro muovano un dito perché "pago-pretendo", o simili attitudini. In tal caso qualcuno potrebbe sempre usare i loro dati, e anzi stavolta lo farebbe in connessione davvero sicura :-)

@109.55: In pratica la falla annullava la funzione principale della protezione SSL, la crittazione, per cui abbiamo navigato in https non sapendo che ci leggevano - diciamo così - con la stessa facilità che se avessimo navigato in http. Non era "più pericoloso", diciamo che "non ha funzionato", ma era opportuno usarlo. Nell'aver scoraggiato molti tentativi di intercettazione da parte di "soggetti" non preparatissimi (che nemmeno provavano sull'SSL credendo anch'essi che fosse blindato), la sua utilità ce l'ha comunque avuta :-) -- g · ℵ (msg) 10:00, 10 apr 2014 (CEST)

(fc) @Gianfranco: capisco cosa intendessi nel tuo messaggio originale; non volevo farti un appunto, intendevo solo precisare che anche i siti ivi indicati come non vulnerable in realtà non sono stati al riparo, onde evitare potenziali equivoci (come quello posto da Superchilum proprio qui sotto) da parte dei lettori meno esperti tecnicamente. --Tino [...] 13:17, 10 apr 2014 (CEST)

purtroppo ho fatto male a mettere quel link così, sottovalutando la possibilità di equivoco, mea culpa :-\ Avevo infatti colto il tuo msg come occasione per provare a chiarire :-) -- g · ℵ (msg) 16:15, 10 apr 2014 (CEST)

Per chi, come me, usa HTTP non cambia nulla :) Jalo 10:10, 10 apr 2014 (CEST)

Gianfranco: ma nell'ultimo link che hai messo, ci sono i siti "vulnerable" (e dobbiamo cambiare la password, no?), "not vulnerable" (e non c'è bisogno di cambiare la password, no?) e "not SSL" (e qui che dobbiamo fare?...). --Superchilum^(scrivimi) 10:10, 10 apr 2014 (CEST)

hai ragione, ho presentato male quel link e me ne scuso :-|
LA PASSWORD VA CAMBIATA COMUNQUE SU QUASI TUTTI I SITI!
Non strillo, scusate di nuovo, è solo per far passare il messaggio più nitidamente e chiaramente:
la falla può essere stata sfruttata per catturare la vostra password, la falla è stata chiusa ma la vostra password potrebbe essere ancora in giro, pronta ad essere usata a vostro nome ma a vostra insaputa.
Il link alla lista dei siti indica soltanto molti esempi di siti su cui potreste avere delle pw da cambiare (esclusi quelli indicati come "no SSL"): l'autore ha solo preso una lista di quelli da cui un hacker "normale", se ne esistono, avrebbe iniziato a intercettare, e lo stesso autore ha testato se erano a posto o meno - ma se anche sono a posto, se la vostra pw è in giro può essere usata, cambiatela :-) -- g · ℵ (msg) 10:22, 10 apr 2014 (CEST)

<brontolone>"non usate la stessa password per tutti i siti, dicevano... se ve la rubano basta cambiarne solo una, dicevano..." e mo' devo cambiare decine e decine di password..... mannaggia....</brontolone> --Superchilum^(scrivimi) 10:27, 10 apr 2014 (CEST)

Il problema è che il bug consente all'utente (l'attaccante) di farsi un giretto nella memoria dell'attaccato, prendendosi 64kb di memoria per volta. Se sono un ladro ed entro in una casa e ho una piccolissima bisaccia che mi metto a rubare? La cosa più preziosa, i certificati X.509! Col certificato posso decrittare il traffico destinato al sito che ho attaccato e posso "impersonarlo". In particolare lo sniffing non è banalissimo nel nostro caso e vedo molto più a rischio gli utenti dei soliti paesi in lista nera e i clienti della NSA. Insomma cambiare password è una buona idea, ma bisogna partire da quelle più sensibili e non farsi prendere dal panico. Nel caso di WMF poi la fondazione parla solo di token ma non mi sono (ancora) informato sul perché. In ogni caso il livello di esposizione è paragonabile a quello dell'http, come fa notare Jalo. --Vito (msg) 10:45, 10 apr 2014 (CEST)

infatti lo spirito è quello del: "è successo il fatto, un piccolo rischio c'è, ma se qualcuno vi impersona su WP, al massimo vi bannano" XD
Poi, a domanda precisa diamo risposta precisa: meglio cambiare comunque, male non fa, e se volete saperlo è meglio cambiare dappertutto. Niente panico, solo un po' di pazienza -- g · ℵ (msg) 11:12, 10 apr 2014 (CEST)

I francesi hanno aggiunto un avviso nel sitenotice Jalo 12:06, 10 apr 2014 (CEST)

Una volta appurata la vera entità del problema (per i siti WFM), credo che la segnalazione tramite sitenotice sia una buona idea. --Jкк ^КGB 12:28, 10 apr 2014 (CEST)

su Commons appare già, nel sitenotice che appare negli osservati speciali (non quello su tutte le pagine). --Superchilum^(scrivimi) 12:35, 10 apr 2014 (CEST)

Io per sicurezza ho cambiato password. --Adalingio 14:22, 10 apr 2014 (CEST)

Io l'ho cambiata. Avevo proposto di cambiare il sitenotice ieri in chat, ma mi hanno detto di non allarmarmi... --Zi' Mazzaró ^{fu Sepp} 14:58, 10 apr 2014 (CEST)

Per non sapere né leggere né scrivere l'ho cambiata pure io, anche perché il mio account è da admin su Commons. Ovviamente non devo essere io a dirlo, ma chi ha funzioni da Admin, Burocrate o (anche peggio) Check-User dovrebbe cambiarla (a margine, Yahoo! mi ha obbligato a cambiare password, tant'è vero che non mi ha permesso di accedere ad alcun servizio se prima non la cambiavo con una forte che preveda almeno un numero e un carattere speciale). Consiglio, dopo avere cambiato la password, di:

1. sloggarsi
2. pulire cache, cookie etc (sia mai che qualcuno ci VADI a smucinare)
3. chiudere il browser e poi ripartire da pulito
4. riloggarsi
5. testare il SUL.

Buon l'Avoro. -- SERGIO ^{(aka the Blackcat)} 17:02, 10 apr 2014 (CEST)

Posto che se fossi un hacker pericoloserrimo di certo non mi metterei a prendere le password degli utenti di Wikipedia (al più quelle dei sysadmin) c'è da dire che il cambio ha poco senso fin quando non saranno sostituiti i certificati, operazione che è in corso in queste ore. --Vito (msg) 21:37, 10 apr 2014 (CEST)

nel messaggio di Greg, che è di martedì, c'era scritto che li avevano già aggiornati: we have already replaced our SSL certs as well as upgraded to the fixed version of openssl. Che stanno facendo adesso? :-O -- g · ℵ (msg) 23:25, 10 apr 2014 (CEST)

Eh, appunto, io davo per scontato fosse stato già fatto... -- SERGIO ^{(aka the Blackcat)} 00:01, 11 apr 2014 (CEST)

Fossi un loacker pericoloserrimo mi metterei a sniffare password per vedere se qualcuno usa la stessa anche da qualche altra parte più "lucrativa". Tutto fa wafer, alla fine (ma non lo sono, ai più esperti dirmi se la cosa filerebbe). In ogni caso, meglio cambiare password (e usarne di diverse su siti diversi e usare questa possibilità ove disponibile). --Toocome ti chiami? 00:51, 11 apr 2014 (CEST)

Too, chi si rivede :-D -- g · ℵ (msg) 00:53, 11 apr 2014 (CEST)

Aloha caro! :) Io ci sono sempre, solo che di solito rivedete il mio IP :P --Toocome ti chiami? 00:58, 11 apr 2014 (CEST)

A questi ACHER ci dovressero taliare il filo del Piccì. -- SERGIO ^{(aka the Blackcat)} 09:49, 11 apr 2014 (CEST)

[← Rientro] Se il cambio della parola d'accesso è così importante per gli utenti con ruoli amministrativi non si può convincere la Wikimedia Foundation ad obbligare al cambio, come è avvenuto alcuni mesi fa per altre falle informatiche? --Gce (Il Vile Censore Mascarato 2013) 15:17, 12 apr 2014 (CEST)

Wiki Loves Perugia, seconda edizione, sabato 12 aprile 2014 (a Perugia)

Segnalo che dopo il buon riscontro della prima edizione, sabato 12 aprile, sempre presso la Biblioteca comunale Augusta di Perugia, si svolge la seconda edizione di 'WIKI LOVES PERUGIA'.

Per i dettagli e per le iscrizioni dell'ultimissimo minuto Wiki loves Perugia.

Wikipediani e bibliotecari di nuovo insieme per inaugurare il nuovo servizio di 'sportello wikipediano' nella biblioteca storica della città: richieste di informazioni, approfondimento, reperimento di fonti... — Questo commento senza la firma utente è stato inserito da Clodcardinali (discussioni · contributi) 18:10, 10 apr 2014‎ (CEST). Segnalo che dopo il buon riscontro della prima edizione, sabato 12 aprile, sempre presso la Biblioteca comunale Augusta di Perugia, si svolge la seconda edizione di 'WIKI LOVES PERUGIA'. Per i dettagli e per le iscrizioni dell'ultimissimo minuto [1]. Wikipediani e bibliotecari di nuovo insieme per inaugurare il nuovo servizio di 'sportello wikipediano' nella biblioteca storica della città: richieste di informazioni, approfondimento, reperimento di fonti...