Perché non dovrebbe usarlo? Non capisco. Risolve il suo problema di attacco.
In tal caso, forse il posto migliore è Marketplace?
Meglio che sia un componente di terze parti a causare problemi piuttosto che un plugin “ufficiale”?
Non sarebbe mai un plugin ufficiale, solo tre righe nel mio account GitHub se Jeff ritiene di volerlo oggi.
Romperebbe l’accesso via email per un sacco di account legittimi. Incluso il mio account email su Gmail.
Sì, ma non credo che tu utilizzi il suo sito.
Un certo numero di vittime civili è accettabile quando si è in guerra. E allora se il 2% degli utenti non riesce a registrarsi, quando sei sommerso da migliaia di email con indirizzi fasulli ogni giorno? È come la modalità “I’m under attack” di Cloudflare: alcune persone legittime non riusciranno ad accedere. È il prezzo da pagare per una sicurezza più rigorosa.
La tua argomentazione è che la modalità “under attack” di Cloudflare non è perfetta, quindi non dovrebbe esistere ![]()
Comunque, avrei bisogno di vedere altri due casi legittimi che confermino che si tratti di un problema su larga scala prima di procedere.
Scusate se mi è sfuggito qualcosa di ovvio, ma non sarebbe più semplice aggiungere reCAPTCHA alla schermata di registrazione?
Questi sono solitamente spammer umani. Ora ce ne sono molti di più rispetto al 2010. I CAPTCHA non servono a nulla contro un avversario umano.
Ok… pensavo che questo tipo di registrazione con “gmail punto e +” fosse fatta soprattutto da bot…
Molte persone reali e genuine usano account come sharklasers e altri (che utilizzano questa funzione) per registrarsi sul nostro sito perché non vogliono che il loro nome utente sia collegato alla loro identità reale. Dipende dai singoli casi.
L’OP può impostare un tempo di lettura di 15 minuti come requisito di fiducia per pubblicare, e richiedere che i primi 5 post siano approvati dallo staff senza diritti di modifica; in tal caso, il suo problema, scommetto, scomparirebbe immediatamente.
Una cosa che vorrei certamente confermare qui è che abbiamo limiti di frequenza ragionevoli per le registrazioni degli account.
Un singolo indirizzo IP dovrebbe essere autorizzato a registrare solo N account al giorno. Tuttavia, abbiamo bisogno di una sorta di bypass o impostazione del sito per i casi in cui il NAT fa sì che un gran numero di utenti condivida lo stesso IP.
Preferisco che il punto . venga normalizzato per Google, ma che +qualcosa rimanga così com’è. Quindi, forse, se intendi farlo, lascia che gli amministratori scelgano cosa vogliono.
È già così… il problema qui è che si tratta del Mossad. Hanno moltissimi indirizzi IP a disposizione.
Sto rilevando limiti di frequenza su:
- accesso tramite email per ora
- invio email di attivazione aggiornamento
- reinvio email di attivazione
- elenco dei fattori secondari
- abilitazione TOTP
- accesso amministratore
Non rilevo limiti di frequenza specifici per la creazione di account, oltre al limite standard integrato per IP.
Chiedo a @markersocial di installare Data Explorer ed elencare gli indirizzi IP di registrazione per il gruppo di utenti che si sono registrati. Voglio sapere con certezza se provengono da 100 indirizzi IP diversi o solo da 1.
Vorrei essere d’accordo, ma Google ha questo problema. Almeno all’università dove ho lavorato, non era possibile far registrare una classe a Gmail perché l’università gestiva tutto il traffico da un unico NAT.
Sospetto che una whitelist per il NAT risolverebbe la maggior parte dei problemi reali, dato che è probabilmente prevedibile da dove provengono gli utenti legittimi.
Impostare di default un numero piccolo (o configurabile) di IP al giorno mi sembra abbastanza sicuro.
@sam - Riguardo agli indirizzi IP, confermo che utilizzo la limitazione degli IP basata su registrazione e accesso e dispongo di un ampio elenco di IP bannati. Posso assicurarti che non si tratta di utenti che creano un numero significativo di account dallo stesso IP; wish it fosse così, perché allora sarebbe possibile bloccarli. L’unico modo per bloccarli attualmente è mettere in blacklist tutte le iscrizioni con Gmail.
—
@codinghorror Esiste un servizio non illegale che fornisce accesso a xx,xxx,xxx indirizzi IP unici per $xxx al mese. Quindi è facile per chiunque procurarsi un’enorme quantità di indirizzi IP, non solo il Mossad
. Ci sono molti altri servizi legali che offrono grandi pool di indirizzi IP, e poi ci sono servizi illegali di affitto di botnet.
Sarei decisamente d’accordo per un aggiornamento all’ultima versione; almeno, scrivere gli script per questa operazione sarebbe molto più complicato, visti i recenti cambiamenti nelle mie sfide/trappole.
Inoltre, vi preghiamo di fornirci aggiornamenti regolari qui, così da poter imparare di più.
Sta ancora accadendo in questo momento?
Grazie mille @sam e scusa se non ho ancora fatto seguito a questo.
Sì, sembra ancora molto fattibile creare molti account usando questo trucco (2.5.0.beta1).
Ad esempio, utilizzando il trucco username+{stringacasuale}@gmail.com, qualcuno ha creato 748 account nelle ultime 10 ore. Hanno già migliaia di account su questo singolo indirizzo Gmail.
Quasi l’unico modo per me per rimuoverli dall’area di amministrazione è andare manualmente su ogni account singolarmente per sospenderli e/o eliminarli. Non è molto fattibile perché quella persona può semplicemente premere un pulsante e creare molti altri account. ![]()
Sembra che abbiano quasi una fornitura illimitata di indirizzi IP, quindi i blocchi/limiti basati sugli IP sono praticamente inutili in questo caso.
Inoltre, continuo a ricevere costantemente un numero piuttosto elevato di registrazioni utilizzando i trucchi del punto e del simbolo + su Gmail.
Ciao!
Sono a favore dell’aggiunta di un’impostazione del sito @codinghorror che disabiliti il supporto per account Gmail duplicati; tecnicamente, aggiungere l’impostazione richiede da 15 a 30 minuti.
Grazie @sam - ti ho inviato un messaggio privato con alcune informazioni aggiuntive che potrebbero essere utili~
La mia vasta esperienza in materia nel corso degli anni mi porta a dire che la maggior parte dei bot spam automatizzati (non tutti, ma la stragrande maggioranza) utilizza la stessa stringa ‘HTTP_USER_AGENT’. Anche alcuni bot spam in grado di falsificare gli indirizzi IP spesso usano la stessa ‘HTTP_USER_AGENT’ (o qualcosa di così palesemente falso che è facile da rilevare).
Il motivo è che la maggior parte dei bombardatori e degli spammer scarica semplicemente un software di spam bot, lo esegue e non sa davvero cosa sta facendo. Sì, ovviamente ci sono eccezioni, ma il 99+% dei bot spam sono solo script/programmi eseguiti da spammer non particolarmente sofisticati che scaricano ed eseguono (in generale non sono giganti della programmazione).
In effetti, a volte queste stringhe ‘HTTP_USER_AGENT’ sono davvero ovvie. Naturalmente, in teoria tutto può essere sconfitto, ma nella pratica, nei nostri forum nel corso dei decenni, abbiamo avuto pochissimi problemi di spam (rispetto ad altri forum) perché assegniamo un punteggio agli indirizzi email in base a vari criteri e rifiutiamo quelli più evidenti (non li moderiamo: quando il punteggio supera una certa soglia [livello di confidenza], rifiutiamo semplicemente la registrazione, perché chi vuole moderare un ampio database di spam? Nessuno). Inoltre, non usiamo Akismet per una serie di motivi (da molti, molti anni), ma non voglio divagare su questo argomento ![]()
Tuttavia, nei nostri vecchi forum vB tutto ciò viene fatto facilmente tramite un plugin PHP, molto semplice da modificare (e per combattere la buona battaglia) in tempo reale. Un tempo utilizzavamo un classificatore bayesiano, ma nel corso degli anni ho trovato metodi migliori. Abbiamo anche utilizzato i cookie, permettendo le registrazioni solo da client che hanno accettato la politica sui cookie (e che permettono i cookie, conformemente alla nostra politica sulla privacy); naturalmente, possiamo leggere un cookie dopo che un utente si è registrato e utilizzarlo per rilevare accessi multipli. Questo blocca la maggior parte dei bot spam, francamente. Non è una scienza spaziale e, a dire il vero, non si basa “solo sugli indirizzi IP”.
Inoltre, per tua informazione, la maggior parte dei bot spam non accetta affatto i cookie, quindi bloccare semplicemente i client che non permettono i cookie aiuta moltissimo.
Non voglio sembrare troppo “sapiente”, ma ho fatto questo per oltre due decenni, ho pubblicato articoli accademici sull’argomento, ho combattuto guerre informatiche in tempo reale in questo settore e ho oltre 20 anni di esperienza nelle tecniche di difesa informatica in tempo reale e anti-spam, quindi so davvero di cosa parlo; quindi, per favore, non essere troppo severo e bloccare la mia risposta se questa funzionalità non è disponibile, non è prevista o non può essere facilmente implementata nell’app Discourse, grazie.
Cerchiamo di essere inclusivi con tutti, in particolare con gli esperti disposti ad aiutare gli utenti.
Ciao.
… 30 secondi dopo …
![]()