Newsgroup: it.comp.os.linux.sys
Titolo: Criptare dati carte di credito

Dei folli mi han chiesto di poter salvare, sul
server, i dati di alcune carte di credito.
Oltre al certificato necessario per l'HTTPS,
esiste un modo per criptare il salvataggio, magari
su file o database, in modo tale che se dovessero
bucare il server (via PHP) non si riesca a
risalire ai dati?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 risalire ai dati?
La risposta breve ï¿œ NO.
La risposta lunga ï¿œ: certo che sï¿œ, ma dato che questi dati devono essere
acceduti da processi non supervisionati, questi processi devono avere
accesso in chiaro (o tenere in memoria, che ï¿œ la stessa roba) alla
chiave necessaria a decrittarli, il che fa sï¿œ che il dato crittato non
sia poi cosï¿œ protetto...
Ciï¿œ detto, quando qualche cliente prospetta quella possibilitï¿œ tendo a
domandargli se si sente tranquillo all'idea di dover rimborsare le
banche per centinaia di migliaia di euro qualora il suo sito venisse
bucato e le carte di credito dei suoi clienti depredate.
Di solito, ci ripensano...
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/

 risalire ai dati?
tu puoi salvare criptato ma se nel php o db c'è il salt e ti bucano 
sei fregato.
io ho sentito di gente modificare fisicamente i cavi di rete e trasmettere 
in udp a un server i dati delle cc, tale server era fisicamente 
impossibilitato a trasmettere i dati.
ora non so se sia una cosa reale o se mi ricordo male ma suonava più o meno 
così...
fatto sta che se devi accedere a quei dati e c'è un buco di sicurezza sei 
sostanzialmente fregato.
-- 
give it away

 un cretino ha scritto:
"Il microkernel e' morto da molto tempo ed ancora non lo sa." (cit. Bluff)

 bucare il server (via PHP) non si riesca a risalire ai dati?
Si, è possibile.
Il problema è che questi dati ti servono comunque in chiaro, quindi ti 
serve la password per decriptarli.
E la password diventa inesorabilmente il punto debole del sistema.
La soluzione più sicura è **non** conservare la password sullo stesso 
server, ma in questo modo complichi il deployment della applicazione.
Ad esempio l'applicazione potrebbe richiedere la password all'avvio; 
questo significa che si deve avviare l'applicazione manualmente, via SSH.
Ciao  Manlio

 come mettere il culo nelle pedate
you made my day :)
9 internets for you
-- 
give it away

 server, ma in questo modo complichi il deployment della applicazione.
Ricordo che dove lavoravo alcuni anni fa, per un problema simile, si
scrissero un programmino che utilizzava Shamir Secret Sharing Scheme
per distribuire la password su più server. Non chiedetemi di più
perchè non ero io a seguire quel progetto.

 perch� non ero io a seguire quel progetto.
E' una soluzione, ma dipende da cosa si deve implementare, perch�
implica la necessit� di mettere una parte della chiave fuori dal sistema.
Il che implica che il sistema non potr� usufruire dei dati memorizzati
(aka: i numeri delle carte di credito) se non c'� qualcuno/qualcosa che
di volta in volta fornisce la parte di chiave mancante.
Se questo qualcuno � automatico, � come se non ci fosse.
Se � manuale, � tutto perfetto, ma tocca fare scorta di cinesi...


 E la password diventa inesorabilmente il punto debole del sistema.
La butto li`:
Usare la password dell'utente come seed per la crittazione dei dati delle 
C/C.
Naturalmente bisogna ricordarsi di decrittare e ricrittare tutti i dati 
delle C/C ogni volta che l'utente cambia password, e rimane il problema 
dell'utente che ha scordato la password e ne chiede una nuova.
Bye.

 server, i dati di alcune carte di credito.
Nemmeno sotto tortura.

Neoviruz ha scritto:

A parte che sembra un  amo buttato lï¿œ, ma non scherzate con la moneta 
diventiamo tutti permalosi, non possono chiederti un lavoro del genere a 
meno che non ti riconoscano la giusta moneta per la responsabilitï¿œ che 
ti prendi.

 [...]
Ciao  Manlio

 server, i dati di alcune carte di credito.
Non vorrei sbagliare, ma per poter maneggiare e memorizzare i dati delle 
carte di credito, le aziende emettitrici richiedono una certificazione di 
sicurezza.
https://www.pcisecuritystandards.org/index.shtml
So che alcuni nostri clienti hanno fatto questa certificazione apposta.
Non so perï¿œ cosa comporti non avere la certificazione e memorizzare o 
trattare ugualmente quei dati, ma penso che sia una questione di 
responsabilitï¿œ civile che non puoi scaricare su nessuno in caso di perdita 
dei dati (e non trovi alcuna assicurazione che ti assicuri da tale evento).


 tale evento).
A bo, io so che ï¿œ una follia, ma questo vogliono e non c'ï¿œ verso
di fargli cambiare idea.

 di fargli cambiare idea.
Lascia il cliente a qualcun altro allora.

 ti prendi.
A parte che non capisco perchï¿œ rispondi a me, in seconda istanza, visto
 il genere di danni che si possono fare trafugando dati di carte di
credito, ribadisco che nemmeno sotto tortura mi farei convincere a
trattare quei dati.

 ti prendi.
Nessun problema per due motivi:
1) il server non ï¿œ mio ma abbiamo regolare contratto con il cliente
2) un avvocato ci ha giï¿œ fatto un documento con scritto: c'ï¿œ ne 
sbattiamo i maroni se si dovesse verificare una qualunque fuga di
dati ed in ogni caso, il problema non sarï¿œ mai nostro
3) analogamente, loro han firmato un foglio (scritto dal loro avvocato)
in cui ï¿œ scritto: qualunque cosa succede la responsabilitï¿œ ï¿œ nostra.
in parole povere: chissenefrega. cazzi loro.
PERO', io sono onesto, e vorrei un sistemino, per quanto labile che sia,
che mi faccia dormire sereno la notte sapendo di aver fatto il 
possibile. Un conto ï¿œ lasciare tutto in chiaro, un altro conto ï¿œ aver
messo una piccola cifratura.
Alla peggio, salvo i dati su database criptandoli in php e poi faccio
criptare anche il file php che 'decripta' le carte con ioncube.




Pensavo a qualcosa di un po' piu` complesso.
In ogni caso la password ti arriva in chiaro quando l'utente fa login.
Al momento del login prendi quella password in chiaro, la critti per 
confrontarla con quella di login, ma contemporaneamente (se il login ha 
successo) la usi anche come seed per decrittare i dati della C/C, e li 
tieni in sessione.
Se ti bucano il server possono rubare solo i dati che hai in sessione 
(cioe` quelli degli utenti loggati in quel momento), invece che tutti 
quelli nel DB.
Bye.

 tieni in sessione.
Usare la password degli utenti mi risulta impossibile.
I dati della carta servono come cauzione, l'utente inserisce i dati,
una seconda persona deve però vedere la carta.
Per cui, la carta deve essere decrittata da almeno de persone:
l'utente che l'ha inserita, ed una seconda persona che deve poterla
leggere.
Entrambe le persone hanno un login alla piattaforma, ovviamente, ma
le password saranno diverse. Se usassi la password utente come chiave
di cifratura, la seconda persona non decritterebbe. Se usassi la seconda
persona, la prima non salverebbe la password.
Come generare un algoritmo in comune ad entrambi?
Mi sa che l'unica è quella di 'staticizzare' una chiave in comune tra i
due utenti, generata in modo semi-randomico (md5 del timestamp con un
prefisso e postfisso a me noti) e criptare anche lo script php contenete
la classe di cifratura/decifratura.
Se dovessero bucare il server, avrebbero le chiave generate in un
algoritmo semi-random, e non avrebbero accesso facile agli algoritmi.
Potrei sempre cambiare l'algoritmo una volta che la carta è stata usata
o ogni X giorni/ore/secondi quel che è.

Nel mezzo del cammin di nostra vita mi ritrovai con Gandalf Corvotempesta
che diceva

Che DB useresti?
-- 
"Le opinioni dei fanatici prescindono dai fatti"
python -c "print 'bG9ybWF5bmFAZ21haWwuY29t'.decode('base64')"
Linux Registered User: 461615

 criptare anche il file php che 'decripta' le carte con ioncube.
sì, questo è un buon metodo per far sì che i dati durino 5 minuti in più 
invece che 3.
xe pien di decompilatori 

 
torna utile allora usare una macchina che fisicamente non può trasmettere i 
dati ma solo riceverli.
la persona seconda ha accesso a quella macchina dalla vpn o quel che è

 la persona seconda ha accesso a quella macchina dalla vpn o quel che è
ma non mi è chiara una cosa, se l'utilizzo è per la persona seconda, non 
puoi salvarli criptati e dare il sistema di decrittazione solo alla persona 
seconda?

 Che DB useresti?
MySQL

 seconda?
Deve farlo via web, accedendo al suo pannellino deve vedere
gli utenti e le rispettive carte di credito lasciate come cauzione.
Anche l'utente, però, ha un pannellino, e deve poter accedere al
sito e vedere le proprie carte.

 Come generare un algoritmo in comune ad entrambi?
Puoi usare un sistema a "slot". Nel sistema a slot il dato da crittografare 
lo critti con una chiave generata casualmente. Questa chiave poi la critti 
sia con la password dell'utente che con la password degli operatori e salvi 
i dati così generati nel tuo DB in campi differenti (detti slot) che 
potranno essere quanti vuoi.
Ovviamente quando l'utente o un operatore farà login decritterai con la sua 
password la chiave in ciascuno slot fino a trovare quello che si sblocca o 
se non ne trovi dando il messaggio di errore, e ibidem con le login degli 
utenti. Questo sistema ovviamente aumenta la vulnerabilità del sistema in 
proporzione al numero di slot che possono decrittare la chiave.
Un sistema poi per tutelare i dati dall'accesso offline può essere quello di 
combinare la chiave di crittografia delle carte con un sistema basato su 
SSSS, Shamir Secret Shared Scheme. Questo consiste nel generare una chiave 
casuale (il secret) e N chiavi ad essa correlate delle quali ne sono 
sufficienti M per svelarla. Questo è il sistema che si usa per dare un 
accesso ad un sistema o ad un insieme di dati solo in presenza di almeno M 
amministratori su N.
In questo caso ciascuno slot lo sblocchi concatenando la password di ciascun 
operatore o dell'utente con un Secret ottenuto da una combinazione con M=2 e 
N=al numero di amministratori che hai in azienda; delle N chiavi generate, 
una chiave la tieni in cassaforte e una la dai a ciascun amministratore di 
sistema che la inserisce nel sistema all'avvio del server.
In questo modo se il database viene rubato serve l'accordo di 2 persone tra 
l'amministratore di sistema e chi ha le chiavi della cassaforte, per 
accedere ai dati, e poi serve comunque la password di un operatore per 
leggere i numeri in chiaro.


 MySQL
Ricordo che tempo fa sulla newsletter di 
sikurezza.org
 c'era un thread 
nel quale si discuteva appunto di cifratura di dati su DB (ma mi sembra 
anche PostgreSQL) e dicevano che Oracle ha la funzione di cifratura 
nativa. Se ritrovo il thread, posto il link


 Puoi usare un sistema a "slot". Nel sistema a slot il dato da 
[cut]
Sai che ti dico? Me ne sbatto altamente e cifro con una chiave
standard. Problemi loro, tanto han firmato un doppio contratto
approvato da entrambi gli avvocati.
In parole povere: cazzi loro.

 In parole povere: cazzi loro.
Tu secondo me non hai ancora ben chiaro il quantitativo di merda che può 
pioverti addosso in caso di problemi.
Certe responsabilità i contratti non te le possono levare; 
p.es
. il fatto 
che la macchina rispetti le misure minime di sicurezza, che sia 
adeguatamente protetta, che sia aggiornata, che vi siano i log degli 
amministratori, che vi siano i backup, ecc.ecc. sono tutte responsabilità 
degli amministratori (aka tua) e in caso di rogne vai tranquillo che anche 
se c'è un bel contratto troveranno qualsiasi escamotage per far ricadere la 
colpa su chi ha sviluppato l'applicazione che non ha usato la diligenza del 
buon padre di famiglia, ecc.ecc. ...
Se succede il casino ricordati che la merda cade a pioggia su tutto e su 
tutti, e l'ombrellino del contratto lo ha il tuo capo, non tu, quindi prima 
che la merda arrivi a lui tu sarai già fradicio. E comunque l'ombrello non 
protegge dagli schizzi.


 tutti
Questo in uno scenario normale.
Quando ci sono numeri di carte di credito rubate di mezzo, arriva a
secchiate ad altezza uomo. Da sopra, da sotto, di lato.
Gandalf[1], fidati, è opportuno evitare di trovarcisi in mezzo,
indipendentemente dalla fiducia che si ha nell'ombrello...
Peraltro, per la casistica che pare di intuire dallo scenario che
descrivi, forse la "cauzione" è gestibile direttamente coi meccanismi
propri dei circuiti bancari (riserva sulla carta di credito) che però ha
l'effetto collaterale di non rendere disponibile la somma "lasciata in
garanzia" e -mi risulta- di richiedere una seconda operazione (di
storno) da parte del cliente finale a "rapporto concluso".
[1] Me pare di parlare col mio gatto...[2]
[2] 
http://bit.ly/bRIJzr


 In parole povere: cazzi loro.
Scusa, ma la banca del cliente non mette a disposizione dei servizi di 
pagamento?
Un mio cliente si appoggia alla sua banca e non ha problemi


 [2] 
http://bit.ly/bRIJzr
ma che meravigliose creature. 
complimenti!

 Lascia il cliente a qualcun altro allora.
[OT]
Ma sei sparito da FB? :-/

 
http://bit.ly/bRIJzr
Meraviglie!

 Un mio cliente si appoggia alla sua banca e non ha problemi
Eh, ma *costa*. ;-)

 [1] Me pare di parlare col mio gatto...[2]
I know :)
Se preferisci, scrivo come Peregrino 'Pipino' Tuc o Lotho Baggins :)

 Un mio cliente si appoggia alla sua banca e non ha problemi
Non è così semplice la faccenda.
I clienti, sono, ad oggi, 148, tutti indipendenti tra loro.
Poi noi abbiamo una unica "entità" che ci ha commissionato
il lavoro per i propri 148 clienti.
La verifica la fa l'entità, ma non vuole ritrovarsi in mezzo
alle transazioni.
Il progetto iniziale era:
- noi prendiamo la carta, la passiamo criptata ad uno dei 148 clienti
(in base alla richiesta fatta dal navigatore) il quale la tiene li
come cauzione.
- se butta male, il cliente scala l'importo usando il codice dalla
carta di credito come cauzione, altrimenti la elimina.
I servizi bancari del mio cliente (ovvero "l'entità") fanno la verifica
della disponibilità economica e non è quello che vuole il mio cliente.
Inoltre, in caso di problemi, uno dei 148 clienti non avrebbe accesso
alla carta di credito, poichè la banca è associata all'entità, e solo
tale entità può scalare i soldi e quindi si ritroverebbe in mezzo
alla transazione.
non so se mi spiego.

 Eh, ma *costa*. ;-)
Guarda che in questo caso, stranamente, non è un
problema economico. E' solo un problema logistico.


[OT]
Ma come vi chiamate su FB? Come si fa a trovarvi con questi nick esoterici?
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo

 sradicando il male dai campi che conosciamo.
Secondo me la soluzione ï¿œ dentro di te.
Parti prendendo ad esempio la tua firma, e inizia a sradicare il PHP.
L'assunto ï¿œ semplice: che ciï¿œ ti dicono di fare ï¿œ fattibile, e se 
parliamo di home banking ï¿œ la cosa piï¿œ comune.
L'altro assunto ï¿œ che i siti in PHP, in quanto a sicurezza, non brillano 
molto.
Che fare allora, visto che i siti di Home Banking non li ha mai craccati 
nessuno?
Buttati su Tomcat, sull'application server della Sun o su ciï¿œ che ï¿œ 
storicamente e intrinsecamente piï¿œ sicuro di PHP.
Non mi pare ci sia altro da aggiungere.



cioï¿œ, c'ï¿œ dell'altro da aggiungere, ma sono sempre le solite cose: 
probabilmente il DB starï¿œ in DMZ...


 Ma sei sparito da FB? :-/
Yep.
Devo ancora decidere se temporaneamente o definitivamente.

 la disponibilità economica.
purtroppo la libreria php-pincode, per inserire i tokenm non l'hanno 
ancora inventata ^_^
Scherzi a parte, butta a mare PHP e inizia a prendere in considerazioni 
altre soluzioni (tipo tomcat) e non disdegnare nemmeno l'idea di 
utilizzare delle token card come sistema di autenticazione.
Gli dici al cliente che, o si fa così, o si rischia che tutto va 
veramente a puttane. Poi gli dici quando costa l'appliance di RSA per 
gestire i token. A quel punto lui, visti i costi, rinuncia al progetto e 
tu ti sei salvato il culo.


 storicamente e intrinsecamente piï¿œ sicuro di PHP.
Che PHP non sia sicuro ï¿œ una stronzata.
E' il programmatore che lo rende insicuro, non il linguaggio in
se per se. Potrei benissimo fare un programma Java totalmente
insicuro mentre uno in PHP a prova di bomba.


Puï¿œ sembrare vero quello che dici se analizzato da un altro punto di vista.
Cioï¿œ: ï¿œ vero che molti siti php vengono bucati. Ma non si tratta certo 
di siti hardenizzati. Spesso si tratta di server dove tu non hai accesso 
al db, che ospitano tantissimi siti su un unico host e blabla
Da un'altra parte, perï¿œ, perchï¿œ PHP non viene utilizzato da nessuno in 
tutti quei campi dove la sicurezza diventa il requisito fondamentale?
Per quanto riguarad tomcat, fa parte dei repository di debian/ubuntu. 
Buttaci un occhio.
Per quanto riguarda MySQL+PHP puoi criptare la comunicazione tra il web 
server e il DB. Ovviamente non userai una comunicazione cia socket file, 
dove tutti i demoni, per risparmiare soldi, girano sulla stessa macchina.
Il punto ï¿œ sempre quello di non fari bucare il web server.



Facebook ï¿œ bello. A patto di non aggiungere tra gli amici gli attuali 
colleghi di lavoro.... e in particolare: mai fare l'errore di aggiungere 
il capo :)


 utilizzare delle token card come sistema di autenticazione.
io di sta roba ne so poco , ma perchè dici di sostituire un *linguaggio* 
con un *application server* ?
forse volevi dire java?
o non conosco tomcat?


ti spieghi, ti spieghi. In modo del tutto amichevole, e molto fuori dai 
denti, ti dico che tu sei veramente fuori almeno per un paio di motivi.
Prima di parlare dei dati crittati, dovresti parlare di architettura nel 
suo insieme, come vorresti organizzare il tutto, e quali tecnologie hai 
in mente di utilizzare.
inizia a parlare del web server, il DB, il middleware, la opportunità di 
creare DMZ verso il DB, le reti e tutto ciò che ci può stare intorno. 
Poi viene tutto il resto e poi forse ti accorgerai che è persino 
superfluo crittare quei dati dei quali parli.
Cose del genere, sono all'ordine del giorno, e vengono fatte in 
continuazione. Quindi non mi stupisce che qualcuno pensi di voler 
memorizzare il tipo di dati del quale parli. Ma non mi convince per 
nulla lo scenario che tu ci descrivi. Questi lavori, anche per la 
questione delle RESPONSABILITA' (che tu sembri non voler capire) vengono 
condotti a team, e di questi team fanno parte lo sviluppatore java, la 
persona che si occupa di tomcat, il sistemista, etcetera etcetera e per 
finire c'è pure un project manager. Il project manager coordina lo 
svolgimento di un progetto. Ma qui viene fuori un'altra cosa: il 
progetto! Dov'è il tuo progetto? Lo vuoi fare su Usenet il tuo progetto?
Caro mio, su Usenet puoi chiedere informazioni su un dettaglio. Ma a te 
non manca una info o un dettaglio. Te, non hai formalizzato nessun 
progetto. Te parli di un server LAMP che fa ridere i polli.
Te parti da un punto sbagliato, e vieni qui a fare la domanda sbagliata: 
come cripto il dato sul mio LAMP?
Io lo so che noi qui dentro siamo tutti persone che mettiamo le mani un 
po' dappertutto. Bisogna però porsi dei limiti, e capire quando questo 
modo di lavorare può andar bene, e quando invece no.
Io qui vedo un Gandalf Corvotempesta che deve fare tutto da solo, su un 
server LAMP che non si capisce se deve girare tutto su una macchina, e 
la cosa, credimi, mi fa veramente ridere.
E quello che ha detto ZipMan (il discorso sulla merda che piove), oltre 
che sacrosanto, mette maggiormente in evidenza il tuo modo frescone di 
approcciare le questioni!
Questo messaggio non vuole essere un affondo nei tuoi confronti, ma una 
incitazione, una esortazione e provare a inquadrare meglio la cosa nel 
suo insieme e ad affrontarla in maniera assolutamente più ORGANICA.
Lascia fottere il file crittato per il momento..... e ritorna alle 
radici di tutto.



si. Mi sono espresso chiramente in maniera errata.
avrei dovuto dire: rimpiazza LAMP con Tomcat.
Mi rendo conto che - dal punto di vista dello sviluppo - non è 
sicuramente facile passare da php a java, ma mi pare anche che sia poco 
ortodosso che una cosa del genere possa essere portata avanti da un 
fac-totum, che nella fattispecie sarebbe il buon Gandalf.
E' tutto l'approccio che è completamente da "fuori di testa".


 Il punto è sempre quello di non fari bucare il web server.
E con tomcat su apache hai ben due webserver che possono avere bug ed 
essere bucati. :P
Bye.

 Se preferisci, scrivo come Peregrino 'Pipino' Tuc o Lotho Baggins :)
No, no, er l'amor del cielo.
Ci manca solo un altro cambio di nick... ;-)


 nessuno?
Avrei *molto* da obiettare al riguardo...


> [2] 
http://bit.ly/bRIJzr
Spettacolo.

 Spettacolo.
Foto vecchiotte: Gandalf e Sauron ormai vanno per i tre anni.
Qui almeno ce ne sono un paio di recenti (anche se manca un gatto)
http://bofhskull.wordpress.com/2009/12/19/neve/
Consiglierei un siberiano a qualunque amante dei gatti.
Almeno i siberiani di Victoria, la nostra spacciatrice di gatti:
http://www.freewebs.com/murmur_s/


 Consiglierei un siberiano a qualunque amante dei gatti.
io ho un siberiano, ho avuto un sacco di gatti ma il carattere di Gregory è 
il più bello di tutti, guarda quanto è bello:
http://img687.yfrog.com/img687/2571/photowl.jpg

 
http://img687.yfrog.com/img687/2571/photowl.jpg
Spettacolo.


 Qui almeno ce ne sono un paio di recenti (anche se manca un gatto)
Belli! Anch'io ne ho tre (+ un cane) il più vecchio (ne fa 11 a marzo..) 
l'ho pure chiamato Linux :)
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 Foto vecchiotte: Gandalf e Sauron ormai vanno per i tre anni.
Uno dei miei si chiama Beren. ;-)

 IBM a coprirgli il sedere.
La Sun ti propone sia php, sia mysql. Non ti preoccupare, non è questo 
il punto.... ho seguito di recente un "webinar" della Sun sul CMS 
"Alfresco" e le tecnologia utilizzate sono php e mysql.
Io non voglio dire che PHP non si usa a livello aziendale (mi pare che 
sono stato il primo difensore di php+mysql), ma semplicemente, non viene 
usato in questi campi.
Il giorno cui dovessi trovare un servizio bancario basato su server LAMP 
fammi un fischio. Mi trovi sempre qua!


 
Beh in effetti sono rari, non perch� vorrebero ma non possono, ma perch� 
fanno prima a mettere su un sito fasullo e lasciare che siano gli utenti a 
dargli i dati di accesso.
Meno, fatica, meno rischi, meno reati penali eventualmente da scontare.

 un cretino ha scritto:
"Il microkernel e' morto da molto tempo ed ancora non lo sa." (cit. Bluff)

 dargli i dati di accesso.
avete info sul defacement del sito di poste italiane? Che tipo di 
attacco � stato?
a me, sinceramente, a parte il sito di poste italiane non me ne vengono 
in mente altri.



chiaro. Il sito php che viene bucato non � un sito monitorato 24/7 e 
bucare un sito monitorato vuol dire farsi sgamare in meno di 24 ore.
Pertanto, sarebbe un'operazione senza scopo. Difatti l'attacco al sito 
delle poste aveva scopi dimostrativi.


 Ma non � che quel che non si sente non esista.
]zac[
Premesso che ho capito cosa intendi precisare.
Per� mi sembra un tantinello azzardato affermare che esista qualcosa di cui 
non esiste nessuna informazioni un minimo verificabile ... altrimenti tanto 
vale affermare che babbo natale esiste ma la notizia non � trapelata ....

 delle poste aveva scopi dimostrativi.
No, in un furto dei dati delle carte di credito  ha poca importanza che si 
accorgano del furto, qualche ora � pi� che sufficiente per mettere a frutto 
i dati rubati, e in ogni caso, come per i soldi rubati e magari 
contrassegnati, mantengono un loro valore nel tempo, per esempio per 
criminali residenti in paese senza accordi per l'estradizione o comunque 
leggi piuttosto permissive.


ok, ok. D'accordissimo con quanto dici.
andremmo a finire su un altro argomento se ti raccontassi come 
probabilmente questi soldi "rubati" tornerebbero facilmente indietro.
Sai la storia del tipo che ti manda una mail e che ti vuole mandare un 
assegno, bla bla....
Ho vissuto con una terza persona questa storia. Non entro nei dettagli 
perch� facciamo notte e vado al sodo: all'inizio gli hanno versato 
veramente di 10mila euro nel conto. Ma dopo una settimana glieli hanno 
tolti nuovamente ... e il gioco di queste transazioni gli � costato pi� 
di 100 �.
Tieni presente che parlo da ingorante sulla materia.


 vale affermare che babbo natale esiste ma la notizia non � trapelata ....
Ma io non ho detto che non esistano informazioni verificabili. Ho detto che 
non trapelano, intendendo che non vengono diffuse ai quattro venti. In tutte 
le banche esiste una gestione degli incident di sicurezza con l'elenco di 
tutti gli attacchi subiti, con le conseguenze, con le contromisure messe in 
atto, ecc.ecc., ma sono tutti documenti riservati che non vanno in giro.
Il fatto � che nel 99.9% dei casi nessun attacco ad un sito bancario produce 
danni concreti (si fermano praticamente tutti al frontend, il backend � 
molto ben protetto) che possano balzare all'onore delle cronache quindi quei 
documenti restano nel reparto IT della banca.


 attacco è stato?
Tu non lo vuoi sapere, davvero. :)


no dai, dimmi. Mi interessa per MILLE ragioni :) evito di enumerare le 
ragioni, altrimenti mi si dice: "ma che un cell'hai nu blogg personale?"
conosco le tecnologie che utilizzano, se è lì che vuoi parare.
O meglio, esiste postecom, poste italiane un'altra entità ancora.
So per certò che postecom utlizza sun one, sun application server and so 
on...


 essere bucati. :P
Dipende da come implementi l'architettura. Tomcat non ha necessariamente 
bisogno di un "servente web" per trasmettere i contenuti al client. 
Comunque, visto che e` stato nominato, eviterei nel modo piu` assoluto il 
pacchetto debian relativo a tomcat, in quanto ha il difetto di sparpagliare 
l'applicazione per tutto il file system quando l'installazione standard 
mette tutto dentro una directory
Enrico

 mette tutto dentro una directory
Taluni lo chiamano difetto, altri lo chiamano rispettare FHS.


 
http://img687.yfrog.com/img687/2571/photowl.jpg
Magnifico...
Io ho 2 persiani.

> 
http://img687.yfrog.com/img687/2571/photowl.jpg
se non fosse così caro invece aggiungerei un gatto egiziano.
solo che 3 gatti in casa farebbero di me un gattaro, e non è ok


beati voi.
Comunque a me piacerebbe una lince, solo che ho paura che si magna pure 
a me :-)
L'ho vista in un parco in Polonia ed è veramente bella: un gatto in 
proporzioni 3:1 o 4:1 :-)


 In parole povere: cazzi loro.
Mah, quoto gli altri che dicono che in questi casi si cerca sempre
un capro espiatorio, e che io non vorrei mai essere nella rosa degli
'incaprettabili'...
Comunque una soluzione potrebbe essere la seguente: ogni tot
(con tot basso, ad esempio ogni mattina) scarichi i dati delle cc
su un dispositivo removibile che viene riposto in cassaforte a
cura del cliente stesso.
Al cliente fai vedere solo una versione depurata dei dati, perch�
quella avrai nel db. Tipicamente 12** **** **** 9004 .
I dati potresti cifrarli a doppia chiave, in modo che tu quando li
salvi li cripti e solo l'operatore con la sua chiave privata pu�
aprirli e salvarseli in un file.
Hai detto che i dati vengono salvati come cauzione, no?
Casomai dovessero servire si va a prendere la chiavetta e si
leggono da l�, ma in modalit� offline e comunque tu l� non c'entri
pi� nulla.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
CBR600F "Cerbero" - In vendita - 
http://www.slimmit.com/go.asp?7X0
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 
puoi cercare un main coone
http://mcgonnigle.wordpress.com/2007/07/15/maine-coon-cats-bigger-than-dogs/
sono super docili e super giganti
http://www.youtube.com/watch?v=ujSTfezSQdc
la lince è impegnativa immagino..

 
Giochiamo a capirci, tu affermi che i crack non sono rari perch� parecchi 
non trapelano, io rispondo probabilmente hai ragione, ma o hai informazioni 
''particolari e non disponibili ad altri'' sull'esistenza di questi crack 
non trapelati o sono pure supposizioni di cui � il caso non tenere conto, 
perch� valgono quanto la mia affermazione che babbo natale esiste.

 perch� valgono quanto la mia affermazione che babbo natale esiste.
Allora diciamo buona la 1.


 Taluni lo chiamano difetto, altri lo chiamano rispettare FHS.
Allora c'e` un problema di fondo. Nel senso, se un'applicazione funziona in 
una determinata maniera, forzarla a funzionare in un'altra non solo e` una 
complicazione, ma rischia di portare problemi non indifferenti. Nel caso 
specifico di Tomcat, il forzarlo a rispettare i dettami della FHS significa 
creare non pochi problemi all'amministratore, che deve quindi cercare di 
comprendere se eventuali problemi sono da imputare, all'applicazione web, a 
tomcat o al fatto che l'installazione non e` conforme allo standard 
dell'application server
Enrico

 dell'application server
Ma il problema � Debian che per rispettare gli standard pacchettizza tomcat 
in modo formalmente corretto ma diverso dalla distribuzione ufficiale o il 
problema � la distribuzione ufficiale che pacchettiza il prodotto in modo 
non conforme agli standard?
Oppure non sussiste problema perch� sia in un caso che nell'altro alla fine 
funziona tutto correttamente se l'applicazione � scritta bene? Sinceramente 
non ho mai riscontrato problemi con il tomcat pacchettizzato da Debian 
(salvo il caso in cui lo sviluppatore cretino che ha scritto l'applicazione 
vi ha inserito hard-coded i percorsi) e la comodit� degli update unitamente 
al sistema operativo � qualcosa a cui difficilmente rinuncerei.
Certo � che la mia esperienza in proposito � molto limitata :-)


 Allora diciamo buona la 1.
scusatemi per l'eufemismo!
Se ce l'hai veramente pi� lungo, l'unico modo per dimostrarlo e quello 
di abbassare la patta e farlo vedere a tutti quanti.
E se non lo fai alimenti ancora di pi� il pettegolezzo da parte di chi 
dice che ce l'hai piccolo.



Molto spesso i pacchetti creati - ad esempio - dalla Sun, sono 
"autosufficienti". Vivono di vita propria all'interno del sistema, Linux 
o Windows che sia.
Sun butta tutto dentro una directory, comprese le dipendenze del 
pacchetto stesso. Spesso ci trovi dentro il suo java e *tutte* le 
librerie che gli servono per girare.
Pro e contro. Questo comunque rende il pacchetto un po' pi� meno a 
rischio di fronte agli avanzamenti di versione del sistema stesso.
Da un'altra parte, sprecherai pi� memoria, per caricare due volte lo 
stesso tipo di libreria.
Dal canto suo Sun fa prima rilasciare il pacchetto in quel modo.


 Gandalf. E' tutto l'approccio che è completamente da "fuori di testa".
Io ad ogni buon conto non capisco cosa ci azzecchi cambiare linguaggio / 
piattaforma con la sicurezza.
Spiegare i vantaggi, per favore.

 Il punto è sempre quello di non fari bucare il web server.
E Tomcat è una scelta giusta tanto quanto Apache/PHP.
Non mi risulta che tu sia anche programmatore, quindi esporsi su tesi di 
"questo linguaggio è più sicuro di un altro" è quanto meno azzardato.


hai ragione.
tuttavia la mia costatazione era basata su quel che vedono i miei occhi.
mai visti servizi bancari basati su LAMP..... almeno fino ad oggi.



ti ho già risposto dall'altra parte. Dandoti in parte anche ragione: non 
sono uno sviluppatore. E in particolare di java non so nulla.
A questo punto sarebbe opportuno che voi deste una risposta alla 
questione che ho sollevato. Posto che nessuno tra i presenti ha mai 
visto servizi bancari girare su un server LAMP, e posto anche che "c'è 
Sun e c'è IBM" mi pare una risposta analoga a quella in cui si dice: "io 
lo so ma non lo dico che i server vengono bucati, però mi devi credere 
lo stesso".
Vedo comunque che qui tutti abbiamo buona memoria: ZipMan è quello che 
cercava una webmail, il cui unico requisito era "basta che non è fatta 
in PHP".   Cioè, si pone problemi per la webmail, e invece non se ne 
pone per i servizi bancari?
Tu ti porresti problemi se una webmail fosse fatta in PHP? Io no.
Tu ti porresti problemi se un servizio bancario fosse fatto in PHP. Io 
qualche dubbio me lo fare venire.
Forse perché storicamente si è iniziato con il java .... non lo so.
p.s.: il PHP non lo conosco bene, perché non lo uso da programmatore. E 
tendo a dimenticare il perl perché lo uso di rado e tutte le volte devo 
andarmi a vedere le cose.


 
cosa ne dici di criptare il numero di carta di credito con una password 
dispositiva che:
a) operatore del sito ha con generatore interno al di fuori del sistema 
online
b) user si genera ed è tenuto a non perdere (fino a un certo punto insomma)
le due password dispositive devono essere diverse.
-- 
give it away

Enrico 'Henryx' Bianchi wrote:

Per curiosità, qual'è l'entità del "problema" ? Cioè, quanto 
"sparpagliamento" c'è ?
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***


mi pare una genialata. E il tutto potrebbe essere la password che fa 
accedere un utente alla tabella di un DB. Il DB sarà remoto, e *NON* 
accetterà ssh entranti dal web server, ma solo comunicazioni sql over 
SSL, provenienti esclusivamente dal middleware. Mi sto perdendo qualcosa?


 SSL, provenienti esclusivamente dal middleware. Mi sto perdendo qualcosa?
sulla carta non vedo problemi, in caso l'utente perda la password farà 
richiesta e operatore uno accederà alla password dispositiva sua per crearne 
una nuova che verrà comunicata con il mezzo più appropriato.

majale wrote:

ah, forse non era chiaro, ovviamente c'è un minimo di overhead ma è 
trascurabile, ossia avere due campi per la carta di credito, ognuna criptato 
con la propria password dispositiva.


Gandalf: passaci il progetto che ci pensiamo noi! :-)


 Gandalf: passaci il progetto che ci pensiamo noi! :-)
sìsì, ma il culo rimane il suo eh!


uahuah :D


 "sparpagliamento" c'è ?
Questo e` Tomcat 5.5 presente su Debian stable (Lenny):
http://packages.debian.org/lenny/all/tomcat5.5/filelist
http://packages.debian.org/lenny/all/libtomcat5.5-java/filelist
http://packages.debian.org/lenny/all/tomcat5.5-admin/filelist
http://packages.debian.org/lenny/all/tomcat5.5-webapps/filelist
Enrico

 prodotto in modo non conforme agli standard?
Direi decisamente la prima. La distribuzione ufficiale di Tomcat e` cosi` 
costituita:
Tomcat (5.5.28)
|-> bin
|-> common
|-> conf
|-> logs
|-> server
|-> shared
|-> temp
|-> webapps
|-> work
Smontare una struttura del genere significa generare eventuali problemi di 
funzionamento all'applicazione che potrebbero non essere prevedibili per 
l'amministratore. Se proprio si vuole fare (quella che ritengo essere) una 
porcata del genere, allora molto meglio ricreare la struttura originale via 
symlink in qualche parte del file system (come avviene ad esempio nei 
pacchetti di qmail e djbdns) e fare riferimento a quella per l'avvio 
dell'application server
Enrico

 solo che 3 gatti in casa farebbero di me un gattaro, e non è ok
*Io* ho 3 gatti in casa.
Sono un gattaro?
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/


perché avete tutti dei gatti? dovreste avere un pinguino piuttosto :P


 perché avete tutti dei gatti? dovreste avere un pinguino piuttosto :P
Beh, i miei son siberiani (2 su 3): almeno mi avvicino al concetto.


 Beh, i miei son siberiani (2 su 3): almeno mi avvicino al concetto.
Se sono chiari (il mio lo e`), secondo me non e` una buona scelta
perche' si sporcano parecchio e volendo mantenerne intatte le
funzionalita` non li puoi nemmeno mettere in lavatrice. Io sono piu`
per i gatti neri o tartaruga, ma a mescola abbastanza fine e scura.

 per i gatti neri o tartaruga, ma a mescola abbastanza fine e scura.
il mio è incredibile quanto sia pulito.
esce in giardino e a volte rientra lurido, ma poi si lava anche per 3 ore di 
seguito.
-- 
give it away