NSA - Non Solo Amiga
TUTTO IL RESTO => Ot(ot) -> .:(@_@):. => Topic aperto da: legacy - 21 Maggio 2018, 23:55:46
-
dead
-
con thehalloween che ha messo un po' di gpdr, a modo suo :o :o :o
Forse troppo
-
O non gli piace il DNS open usato
O non gli piace il fatto che il sito sia HTTP, piuttosto che HTTPs
-
Prova ad accedere da qui (http://93.55.217.0//wonderland/reloaded/durcheinander/) :o :o :o
L'indirizzo diretto funziona meglio. Sono riuscito ad accedere usando i miei vecchi soprannome a passaparola.
Pero' non riesco a vedere dentro il baule.
-
Tutti i collegamenti che mi hai listato mi portano sempre sul paese delle meraviglie, oppure CISCO mi dice no - non si puo'.
Mi sa devo provare da casa.
-
Quest'ultimo ha un check per le dimensioni dello schermo (e del browser usato) e vorrei che fosse fruibile anche sugli smartphone dove lo screen e' tipicamente 420x260 o giu' di li :o :o :o
Non hai bisogno di controlli programmatici (es. in JS) per adattarti alla dimensione dello schermo, basta che usi un layout flessibile, che HTML di suo nasce già, devi solo star attento o a non dare dimensioni o posizioni fisse (che non siano in %) in CSS (eccetto per un eventuale min-width che volente o nolente a un certo punto dovrai dare una dimensione minima al sito), oppure organizzare elementi (tipo pulsanti) in tabelle (che è un enorme taboo nel web-development moderno).
Diciamo che la tua home page già adesso è largamente flessibile; l'unico problema sono i tre pulsanti principali (vedi prima figura); si potrebbe risolvere la cosa togliendo la table e mettendo dei div flottanti a sinistra (così quando non c'è spazio a destra cadono uno sotto l'altro), oppure inserirli in un layout flessibile in modo che si ridimensionino.
Come buona pratica sarebbe da evitare di usare le table per il layout, però metodi "comodi" per ottenere lo stesso risultato (flexbox) sono tecnologie relativamente moderne (HTML5 e CSS3), e assumendo che si voglia lasciare il sito accessibile a browser più vecchi, si può lavorare con le table in layout fixed:
<table style="table-layout: fixed; width:100%; max-width: 600px; margin: 0 auto 0 auto">
<tbody>
<tr>
<th>
<a href="reloaded/durcheinander/">
<img style="width:95%" src="index_full_data/icon-harlock.png" alt="Durcheinander (secteur privé)"></a>
</th>
<th>
<a href="chunk_of/stuff">
<img style="width:95%" src="index_full_data/icon-folder-pirate.png" alt="Chunks"></a>
</th>
<th>
<a href="reloaded/bazaar/mylast.php">
<img style="width:95%" src="index_full_data/icon-marketplace.png" alt="Bazaar"></a>
</th>
</tr>
<tr>
<th>Durcheinander</th>
<th>Chunks</th>
<th>Bazaar</th>
</tr>
</tbody>
</table>
Come tocco finale metterei un "min-width: 350px" sullo style del body, e ottieni un risultato come nella seconda figura.
-
ma come fai ad avere 3000-mila pixel scrreen? un errore-di-sbaglio? un magheggio alla Neo dentro matrix? magia voodoo? :o
Con uno schermo 21:9 8)
Ho solo dovuto vendere un rene e mezzo ma poi sai che visuale. :o
-
ed con un suggerimento di TheHalloween ha addirittura trovato un modo per embeddare le immagini (le icone) nelle stesse pagine HTML: a me sembra magia pura :o :o :o :o
E in efetti e' sconcertante vedere i base-64 di SVG e PNG nei siti moderni, mi chiedo nella mia parziale ignoranza dei framework moderni se sia fatto a manina o usando i vari webpack e soci...
-
Cosa ne pensate?
Che in questo modo potresti non presentare l'agreement a una persona che putacaso ha lo stesso IP di un'altra che ha già confermato (ad esempio se entrambi stanno su una rete privata che esce dallo stesso IP pubblico).
Comunque noto che c'è tanta confusione dietro cosa dice e non dice il GDPR: non è che dice di non dover memorizzare nessun dato sensibile, ma semplicemente dice che ogni volta che tu memorizzi un dato sensibile, devi documentare per cosa lo usi, perchè ti è necessario memorizzarlo e per quanto tempo prevedi di memorizzarlo. Diciamo che "l'innovazione" del GDPR rispetto a leggi precedenti (complesa la porcata italiana) è che non ci sono più regole fisse e checkbox da riempire per essere in regola, ma regna il concetto di risk assestment dove tu gestore del dato sensibile dichiari i tuoi processi, le tue motivazioni, e i metodi che usi per memorizzare, gestire e proteggere il dato sensibile.
Considerando che (credo) tu non devi memorizzare alcun dato sensibile anche solo per leggere il contenuto del sito pubblico (quindi non ti serve essere loggato), non dovresti aver bisogno di mostrare alcuna informativa, mentre ad esempio quando un utente si registra o accede per la prima volta con un nuovo profilo, puoi presentare la schermata di accettazione e quando l'utente conferma ti segni un booleano nel database per dire che l'utente ha accettato l'informativa. In questo modo non hai bisogno di trafficare con i cookie quando un utente non è loggato, e quando uno è loggato avrà o un cookie o il token di sessione nell'URL (come fanno vari framework se si accorgono che i cookie sono disabilitati), e quindi con quello puoi risalire all'agreement guardando i dati dell'utente associato a quel token.
-
il commento di Madame, in coro con TheHalloween: - Some people are too paranoid, seriously
Nun me fa commenta' :/ - cmq parlando degli steits la paranoia e' quasi un requisito nazionale...
-
mi chiedo, ma sarebbero contenti, o continuerebbero a rimbalzare queste frignacce in giro per la rete?
e' la seconda che hai detto
-
2) e che tra browser e server, anche senza HTTPs, ci sarebbe un tunnel criptato
Occhio che hashare la password sul client non vuol dire "cifrare", perchè l'hash stesso diventerebbe la password: metti che la password "hunter2" viene hashata in "12345", e viene inviata al server (che eventualmente fa un secondo hash+salt per compararla a quella memorizzata nel DB), effettivamente è come se "12345" fosse la password in se, e quindi al malintenzionato che ti ha fatto MITM e ha letto il traffico basta fare un replay della tua procedura di autenticazione (trasferendo quindi l'hash) per farsi tornare un token di autenticazione.
E' vero che questo impedisce al MITM di avere la password originale ("hunter2") (semprechè la funzione di hash eseguita dal client sia crittograficamente forte, altrimenti con delle semplici rainbow tables si possono trovare vari plaintext per un certo hash), però non previene la protezione dell'account.
-
Client-Server asymmetric encryption
Chiamasi HTTPS. :D
è inutile creare soluzioni "casalinghe" quando ci sono sistemi già rodati inclusi nei browser.
Qualsiasi browser che supporti Javascript già implementa HTTPS, ed è attivo anche se l'utente ha disabilitato gli script.
Inoltre JS è decisamente più lento di un codice nativo, nonostante gli incredibili JIT che ormai includono tutti i browser principali.
-
I could be at the risk of catching a virus or something, I went ahead and clicked on your link. It took me to a page that immediately made me feel my computer was imminently about to receive some nefarious code. I'm really jumpy when it comes to my computer so you'll have to forgive me.
LOL
Poi magari si scarica l'update di flash farlocco che viene su dal popup di ytmp3 :(
-
::) ::)
-
Plz do some reading about storing passwords, hashing on its own is not common practice! Never roll your own, md5 and base64 is so trivial to reverse you might as well store plain text. Fix that before worrying about https.
questa e' vera? se si, cosa si fa?
Si, è vera. MD5 è molto semplice e quindi velocissimo da computare ed inoltre ha diverse vulnerabilità scoperte.
Per memorizzare password come minimo serve una funzione di hash crittografica, come la serie SHA, anche se è meglio già oggi orientarsi verso SHA-2 visto che per SHA-1 è stata trovata una collisione.
Però la soluzione "moderna" (fra virgolette perchè esiste da vent'anni) è usare delle funzioni di hashing specificatamente studiate per memorizzare password, come bcrypt e la più nuova scrypt. L'idea di queste funzioni è che applicano una procedura in più iterazioni (come parametro configurabile) in modo da rendere molto più lenta l'operazione di hashing; l'idea è che un uso corretto della funzione (ovvero controllare la password) è una operazione una-tantum e quindi anche se è un po' più lenta non è un problema, mentre i metodi brute-force vengono penalizzati. Il parametro di iterazione è configurabile e sarebbe da aumentare man mano che la potenza di calcolo media aumenta in modo da mantenere circa costante il tempo che sarebbe necessario per un completo brute-force.
Quindi, "cosa si fa?": usa o bcrypt (http://php.net//manual/en/function.password-hash.php) o se puoi scrypt, con l'opportuno salt e un parametro di iterazione più alto possibile senza inficiare nel carico del tuo server (a spanne direi di tararlo in modo che impieghi circa 100ms a password)
Riguardo la cosa del GDPR, come tutte le cose lui non "forza" o "richiede" nulla, sta al gestore del dato fornire un risk-assestment riguardo alle soluzioni che implementa per garantire la sicurezza del dato.
C'è comunque da tener conto che il linguaggio del GDPR richiama sempre lo "stato dell'arte" nella tecnologia di protezione dei dati, e in un certo senso "si aspetta" che venga seguito lo stato dell'arte, ovviamente dove possibile e senza esagerare (nel senso che un panettiere non è tenuto ad avere un datacenter con guardie armate).
Vedi ad esempio: https://gdpr-info.eu/art-32-gdpr/
Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk [...]
Quindi diciamo che tu puoi anche fare a meno di applicare la cifratura al trasporto, però è molto probabile che se mai qualcuno dovesse avere i suoi dati personali rubati da un attacco MITM mentre navigava sul tuo sito, probabilmente ti contesteranno che HTTPS è una tecnologia diffusa e di economica applicazione (economica sia di tempo che di danaro) e quindi non aveva senso non applicarla.
Ovviamente non sono un avvocato quindi prendi quello che ho detto con un grosso grano di sale. ;D
-
- ti tocca per forza comprare un dominio, che sono come minimo 20-30 Euro all'anno
Nah, riesci a trovarli anche intorno a 10-15 (e tipicamente il primo anno de lo danno a prezzo stracciato, quindi puoi anche provare e poi farlo scadere).
Per esempio ho provato la procedura per acquistare downthebunker.com su register.it e te lo danno a 0.90 per il primo anno, e quando ho scelto 2 anni mi faceva 24 euro, quindi 12 all'anno. Ovviamente pagando subito 10 anni ti fa 10.2 all'anno ma non credo sia una soluzione.
Probabilmente vorrai comprare anche la "protezione identità" che non mostra i tuoi dati nel whois, però a mente non ricordo quanto costa.
EDIT: un amico mi ha indicato questo registrar: https://www.namesilo.com/
Ci ha comprato un dominio .bid per 1.89$ con protezione whois inclusa.
che e' un costo pure, visto che a noi di quattrini non ne entrano, che ci stiamo gia' mettendo corrente, macchine (che accese 24h/24 si usurano e vanno considerati i ricambi), oltre che tempo personale
Fai una seria valutazione su questo, perchè ormai i servizi di hosting VPS sono molto più convenienti rispetto a gestire l'hardware in proprio: il tier base su DigitalOcean o Linode è di 5 dollari al mese e anche se ti danno un core e mezzo giga di ram girano su mostri Xeon e quindi viaggiano di brutto; inoltre hanno connettività gigabit o superiore verso Internet (Linode addirittura ha un download verso il VPS di 40 Gbps su tutti i tier :o)
Probabilmente se fai anche solo il conto dell'elettricità che usi per tenere acceso un bidoncino che fa da server ti escono più di 5 euro al mese, specialmente qui in Italia dove la corrente costa un botto...
non vedo come possano sfondare il modulo di autenticazione
Di solito quando si parla di brute-force non si intende che attivamente fanno tentativi di intrusione, ma si assume che ti hanno già rubato i dati dal database e quindi hanno già l'hash di destinazione che devono cercare di matchare con un qualche plaintext.
cosa te pare dell'autenticazione tramite hash di un file da uploadare piuttosto che password da digitare?
droppo questa cosa, lascio la classica password da digitare, o entrambe, selezionando poi quale si desidera usare?
Dal punto di vista della sicurezza non fa né caldo né freddo: una volta che il file gigante è stato hashato, hai ridotto l'informazione alla lunghezza dell'hash, e all'attaccante basta solo trovare qualche testo che genera lo stesso hash del tuo file gigante.
Io direi di lasciare solo la password tradizionale e implementare l'hashing con quelle funzioni che ti descrivevo prima; in questo modo saresti già meglio del 99.9999% dei login "fatti in casa" che ci sono su Internet.
-
quindi, questi "tizi", visto che non sono capaci di creare una nuova coppia nick/password, possono usare il vecchio nick ed usare un file al posto della password, e ... la cosa dovrebbe mettere a tacere una volta per tutte RadionDick e tutti i suoi seguaci
Ma io non riesco ancora a capire questo ragionamento: la gente sta veramente venendo da te a dirti "gne gne non mi registro sul tuo sito perchè altrimenti usi la password per accedere a tutti gli altri siti con cui ho la stessa password" ?
Non si rendono proprio conto che stanno facendo la figura dei ritardati mentali? Probabilmente si meriterebbero anche di vedersi gli account compromessi (non certamente da te, ma prima o poi un sito che usano sarà violato e allora tanti auguri).
Inoltre è palese che se qualcuno viene a dirti tali ritardaggini è solo perchè vuole diffamarti; se implementi la cosa dei file probabilmente direbbero che quando fai l'upload tu gli formatti il disco e mandi tutto al governo russo...
-
A proposito di VPS, io mi sto trovando veramente bene con questo : https://www.time4vps.eu
Ci tengo su un serverino per EmuLa (il frontend per gli emulatori che ho fatto io), ci gestisco le attivazioni dei seriali e ci colleziono un po' di statistiche dai client.
Mi sono beccato una promo a 20/anno per questa macchina :
OS: Ubuntu 16.04 (64-bit)
Processor: 1 x 2.4 GHz
Memory: 1024 MB
Hard disk: 40 GB
Inodes: 1,000,000
Bandwidth: 100 Mbps (Monthly limit: 2 TB)Fanno i backup giornalieri e settimanali a gratis, ma per un ripristino ti chiedono 10€ e non ricordo male.
-
A proposito di VPS, io mi sto trovando veramente bene con questo : https://www.time4vps.eu
Interessante, non lo avevo mai visto.
Attenzione che la versione "standard VPS" in realtà non è un VPS come tipicamente si dice ma è un container OpenVZ (lo scrivono nei FAQ); non che sia niente di male, ma è giusto tener conto quando si comparano altri provider. I VPS "veri" sono quelli sotto "KVM Linux VPS".
Interessante la scontistica che viene applicata quando si acquista annualmente/biannualmente.
ieri sera, dietro suggeriento di Z80fan (che ringraziamo tutti), abbiamo preso un dominio (http://www.downthebunker.xyz/) a 2 euro
;D
-
Io userei un cookie normale e basta. Se un utente cancella i cookie o imposta il suo browser per rimuoverli a fine della sessione, per definizione sta indicando che vuole essere "dimenticato" e quindi ha senso che il sito ogni volta creda che è un utente nuovo, i.e. gli riproponga l'accettazione della privacy.
Sui browser che lo supportano puoi usare l'HTML5 Web Storage (https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Client-side_storage), che ha il vantaggio che non viene trasmesso al server e rimane totalmente in locale; se il browser non lo supporta fai un fallback sui cookies.
-
arrivano, per fortuna, anche messaggi incoraggianti
thanks for taking care of those machines from the good old days! I wish your site much success and hopefully it will attract lot of people to ensure much SGI/HP stuff will survive ;-)
Vedi che non sono tutti cattivi!
;D
-
Vedi che non sono tutti cattivi!
;D
Ma non sono cattivi, solamente son cosi' egocentrici e hanno la testa infilata cosi profondamente dentro le chiappe che possono diagnosticarsi problemi allo stomaco a vista!
-
Hihi, io fossi in te lo collegherei ad una webcam : un solo sguardo sul pulsantone ed il messaggio finisce nel cesso :D
Perchè sprecare inutili energie motorie per certi elementi?
;D ;D
-
Un offerta che non puoi rifiutare :(
-
Con sta gente che usa metodi maFFiosi non so quale sia la tattica giusta per reagire :(