Newsgroup: it.lavoro.informatica
Titolo: I geni

I geni acquistano un prodotto di ecommerce da altri geni loro pari,
una meravigliosa suite scritta nei linguaggi più moderni e fighi, 
MA (c'e' sempre un "ma" dietro l'angolo)
cosi tanto per dire, i numeri delle carte di credito dei clienti non
vengono criptati nel db, ma stanno li ben in chiaro a disposizione del
primo pirla che passa (ed i pirla girano, o se girano e gli si da'
pure diritti di admin sul db)
Quindi i geni ci rimangono molto male quando un bel giorno gli omini
grigi (che non sono alieni ma gente che veste una divisa militare)
vengono a bussare alla loro porta e gli fanno un mazzo tanto.
 
Il punto e' come si giustificano davanti al giudice? Invocando la loro
ignoranza e di essere stati "circuiti", "ingannati" dai geni
produttori della "famosa" piattaforma di ecommerce? Si, cmq il giudice
non gli ha creduto

 ha
scritto:

ti ho quotato tutto per eventuale futura memoria :)
in questi come in motli altri casi :
volere cammello ?
vedere moneta !
felice_pago
la mia obfuscation e' indifferente
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 non gli ha creduto
Manca un'informazione essenziale: il prodotto gli era stato "certificato"
dal produttore come "sicuro" oppure no?
Perche' se io vendo salsicce, non ho l'obbligo di legge di avere le 
cognizioni tecniche per sapere se il software che compro per vendere le
salsicce online agli eschimesi e' sicuro o no. Sono obbligato a comprare
strumenti certificatamente sicuri, ma se il produttore mi certifica il 
falso io che fo?

 una meravigliosa suite scritta nei linguaggi più moderni e fighi,
A questo punto è necessario il nome del prodotto, così se qualcuno ce l'ha 
si mette in guardia...

Suarez (dall'ufficio) ha scritto:

Non ho capito, c'è una legge che obbliga a criptare i numeri di carta di 
credito nel db?

 di credito nel db?
Direi che avere un db in chiaro dei numeri di carta di credito, a 
prescindere da cosa possa dire la legge a riguardo, sia un'immensa 
cazzata.
-- 
Son giunto alla conclusione che, almeno una volta nella vita, bisogna
usare Windows a fondo, perche' e' un'esperienza che rende uomini.
Almeno, io, dopo, ho sempre due palle cosi'.
                                                            Leonardo 
Serni


Criptare i db non mi pare ma l'apertura diretta o indiretta del db deve 
essere preceduto da una password, queste modifiche ai miei sw mi hanno 
chiesto i consulenti dei miei clienti per via della privacy.
Ciao 

 
Se sul db adotto adeguate misure di sicurezza i dati sono comunque 
protetti. La critica dovrebbe essere semmai su come sono state gestite 
le politiche di accesso ai dati. se di dati criptati si vuol parlare 
allora perchč non criptare tutto?

GeorgeDomotico - IW2BVB ha scritto:

Sicuramente, ma è appunto un'altra cosa.

il 20/07/2007 0.29, Scrive Roberto C. 40638544:

No, ma c'e' una legge che ti obbliga a limitare l'accesso ai dati 
sensibili. Criptare uno o piu' campi del DB non serve a niente se non 
hai limitato l'accesso alla chiave di lettura.
Per cui l'ipotetico problema dell'ignoto prodotto di cui si parla, 
potrebbe essere quello di non fornire metodi di accesso ai dati 
sufficientemente controllati, non tanto il cripting del db.
-- 
Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñejoAlcoolInside
Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

il 19/07/2007 16.17, Scrive Suarez (dall'ufficio) 40638544:

Probabilmente il giudice ha valutato altre cose, ad esempio la gestione 
delle politiche di accesso al DB, che a mio avviso competono a chi 
gestisce il DB, non tanto a chi scrive l'applicazione.



Vediamo di non esagerare... qualsiasi sviluppatore che memorizza in chiaro
password, numeri di carta di credito, informazioni di accounts, e altri dati
cosě importanti in chiavi di registry, file di testo, campi di DB, č un gran
pirla.
E adesso vienimi a dire che implementare la criptazione/decriptazione di
questi dati aumenta lo sviluppo del prodotto del doppio...
Ciao, Alessandro

 ha
scritto:

du iu conosc pisanu ?
no ?
ahi ahi ahi
ps:
volere cammello,
vedere moneta
se comprano consulenti di mmerda,
avranno prodotti al top
con applicazioni sviluppate e gestite di mmerda


 questi dati aumenta lo sviluppo del prodotto del doppio...
se la ponevi in altro modo, lo avrebbe fatto :)


 la mia obfuscation e' indifferente
M.
-- 
 >> Peter: "ma non avete un cazzo da fare nessuno?"
 > Muntzer: "Io mai, mi rompo il cazzo che è un lavoro brutto".
 > M.

 un briciolo in più di produttività.
ah ecco non cambio azienda, mi adeguo :(
felice_pago
la mia autostima e' indifferente


la mia autostima e' indifferente
appunto.
qualche info in piu' cmq e' dovuta, il caso mi e' stato sottoposto da
un amico avvocato che ha asunto la difesa dell'azienda acquirente per
il processo d'appello ed era alla ricerca di qualche "appiglio" (tra
di noi mi ha detto di considerarlo il classico "bambino nato morto"
che il modo con cui spesso i "principi" della professione forense
indicano le c.d. cause perse in partenza).
La mia idea di base e' che non vi sia sicurezza applicativa o
progettuale che tenga se un malintenzionato ha privilegi di
amministratore di un sistema, e' solo questione di tempo in quei casi.
cmq esaminando le perizie del ctu e del ctp mi ha sorpreso la
"leggerezza" con cui la ditta produttrice del software in questione ha
affrontato la questione della riservatezza (non utilizzando delle
piccole "accortezze", tipo appunto il criptare i dati sensibili del
pagamento, che imvho costituiscono il minimo sindacale in certi tipi
di applicazioni). Ancorche' la responsabilita' del cattivo uso di tali
nformazioni nel contesto di cui sopra non puo' non essere addebitata
all'azienda acquirente del prodotto, ci sono sempre imvho margini per
potersi "rifare" successivamente sull'azienda produttrice della
piattaforma di ecommerce per i danni che le sue carenze progettuali
hanno causato, carenze che rappresentano cmq (ripeto) il minimo
sindacale dell'attenzione da rivolgere a tali questioni.  

 deve pagare necessariamente il doppio.
Non e' questione di prezzo.
Se ci sono delle leggi, non possono essere ignorate, tanto per
risparmiare, non e' molto diverso dal vendere software pirata.
Per quanto riguarda le carte di credito, non conosco la
regolamentazione attuale, ma fino a qualche anno fa non era
neanche possibile memorizzarle (criptate o no). Il servizio di vendita
mandava le informazioni direttamente alla banca
(o altra entità' autorizzata al trattamento di questi dati) la quale
rispondeva con una autorizzazione alla vendita.
Nel nostro caso la pagina su cui l'utente inseriva i dati era
direttamente servita dai server della banca.
Al pensiero che il database di un pinco pallino contenga dati
anagrafici e numeri di carta di credito mi preoccupa un po'...
(il giorno che il DBA decide di lasciare la ditta si fa un bel dump
dei dati e comincia spendere a destra e a sinistra...)
Saluti,
Fabio

 sindacale dell'attenzione da rivolgere a tali questioni.
sai il titanic fu venduto come inaffondabile,
peccato che quello stronzo del comandante
si fosse arrapato a vere sculettare una gran figa
nella sal da ballo numero x, e fosse sceso a provarci !
ps:
volere cammello,
vedere moneta
felice_pago
il mio sviluppo e' indifferente


e ti rimangi la tua idea di base :)
bhe' le aziende hanno pure da qualche tempo dovuto predisporre dei
documenti per la sicurezza in cui teoricamente hanno preso degli
impegni riguradanti la gestione dei dati, se li e' scritto che per i
dati sensibili vanno poste in essere certe misure e poi quelle misure
di sicurezza non vengono messe in atto e' vero che io di fronte al
malintenzionato non posso fare nulla, ma insomma lasciargli la porta
aperta ela luce accesa mi sembra eccessivo...  

D'accordo con chi dice che bisogna vedere le specifiche tecniche
relative alla presenza di criptatura dei dati nel contratto di
fornitura.
PERO'
qui mi sembra che entrambe gli avvocati non fossero molto informati
sulla materia visto che la legge prescrive la messa in sicurezza dei
dati A CHI NE EFFETTUA IL TRATTAMENTO, non al mezzo.
In pratica, è l'azienda che ha acquistato il sistema ecommerce che
doveva accertarsi che i dati fossero criptati e quindi inaccessibili a
chi non autorizzato.  Per quante 'carenze progettuali' ci fossero nel
software, è molto probabile che la sentenza stabilisca che l'azienda
acquirente è responsabile di non aver acquistato un mezzo idoneo al
trattamento dei dati dei suoi clienti, mancando anche di verificarne
l'effettiva sicurezza. Se poi sapeva addirittura che non venivano
criptati...
L'unica cosa che è a favore dell'azienda acquirente può essere il
fatto che da qualche parte sia dichiarato che i dati venivano criptati
in ottemperanza alle vigenti leggi sul trattamento dei dati ecc.

 si tratta di due app differenti 
Come dicevo... "come" gli e' stato venduto, questo pacchetto? Il venditore
ha scritto da qualche parte che i dati erano gestiti con sicurezza?

in ottemperanza alle vigenti leggi sul trattamento dei dati ecc.
quoto in toto anche a futura memoria, infatti il mio consiglio
all'amico avvocato e' stato di sbrigarsi con il processo di appello ed
una volta avuta la sentenza definitiva fare causa all'azienda
produttrice che nelle sue brochure esalta gli standard di sicurezza
del suo prodotto.

 del suo prodotto.
publicita' ingannevole, forse, 1000-2000 euri di
sanzione amministrativa ?
felice_pago
la mia legge e' indifferente


 credito nel db?
Voglio proprio sperare di si.
Addirittura l'imsi delle SIM Card ormai viene criptato praticamente da
tutti gli operatori telefonici nei propri DB. Spero proprio che valga
anche per i numeri delle carte di credito.
Ciao,
Marco.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 con applicazioni sviluppate e gestite di mmerda
allora la domanda era "du iu conosc maroni/legge 30" ?
Ciao,
Marco


 chi non autorizzato. 
Ma e' sempre li' appunto che casca l'asino: accertarsi COME? Nessuno e'
fortunatamente tenuto per legge ad avere profonde cognizioni tecniche
per scavare dentro qualsiasi prodotto che adopera. Si vuole obbligare
ognuno a far effettuare una costosa perizia di terzi su ogni applicazione
che si acquista perche' se il fornitore dichiara il falso e ha un buco
la colpa e' TUA?

 per scavare dentro qualsiasi prodotto che adopera.
mi sembra un po' il teatrino dell'assurdo, non il teatro :),
te vuoi fornire servizi IT ti doti di una struttura IT, compri prodotti IT
e mi dici che NON devi avere competenze tenniche IT ?
resta sul pezzo e non venirtene di nuovo con le salsicce pliz :(
se il cliente finale perrisparmiare a comprato la carne
a basso macello, sono cazzi suoi, quando configuravano l'attrezzo
nessuno si e' accorto che la select *
mostrava dei numeri di CC ?
no ?
cazzi loro pagano in multa quello che hanno risparmiato, ?,
in carne umana !
du iu remember :
volere cammello
vedere moneta ?
felice_pago
il mio cammello e' indifferente


 Ciao, Alessandro
Dipende cosa intendi con "aumenta lo sviluppo del prodotto del doppio"
Prova ad andare in Ericsson e chiedergli quanto valutano il costo orario di
una persona che lavora sulla cifratura dei database di Tim/Telecom.
Ciao,
Marco.


 resta sul pezzo e non venirtene di nuovo con le salsicce pliz :(
Ok, resto sul tecnico: invece che salsicce voglio vendere Ipod :)
Ora, per vendere Ipod NON devo fornire servizi IT e NON mi devo dotare di
una struttura IT: stacco un assegno ad un carrier che mi fornisca LUI i
servizi IT per l'affitto di un server dedicato presso la SUA struttura,
che il carrier fornira' gia' installato e configurato secondo le specifiche
richieste dall'applicazione che intendo usare.
Fin qui ci siamo? Le sole competenze che mi sono richieste fino a questo
punto consistono nello scrivere zeri sul suddetto assegno :)
A questo punto: sorvoliamo sull'ipotesi che ci si rivolga per l'occasione
ad un consulente esterno; diciamo che l'applicazione la metto su da me.
Tutto quello di cui ho necessariamente bisogno sono le competenze necessarie
ad installare, configurare ed utilizzare l'applicazione - in soldoni,
essere capace a leggere il manuale operativo. Se l'applicazione e' scritta
decentemente, probabilmente seguire il manuale e' tutto quello che ti
serve per essere operativo.
Adesso: PERCHE' accidenti io devo conoscere per filo e per segno tutti i 
cazzi interni dell'applicazione? Che cosa me ne frega a me? Nessuno mi
chiede di conoscere la termodinamica il ciclo Otto e l'ingegneria dei
motori a combustione interna per guidare la macchina fino alla birreria.
Perche' dovrei necessariamente sapere allora cosa fa l'applicazione "dentro"?
So quello che deve fare e tanto mi e' necessario, "come" lo fa sono affari
di chi l'ha realizzata. Mi si puo' ragionevolmente chiedere di comprendere
tutto cio' che e' necessario al suo utilizzo - ma la struttura interna
del database ed il formato dei dati, che me ne importa a me ??? Qual e'
il senso che io lo sappia ?? 
Cio' di cui mi devo ragionevolmente interessare, nel contesto in questione,
e' che il fornitore dell'applicazione mi abbia messo nero su bianco
che il trattamento dei dati contenuti risponde alle norme di sicurezza ecc.
ecc. Se NON me ne sono interessato allora sono un fesso perche' ho
mancato ad una precisa disposizione di legge - ma non perche' non sapevo
com'e' fatto dentro, ma perche' non mi sono fatto rilasciare una
certificazione. Se invece mi hanno rilasciato una certificazione falsa,
oh, che dovevo fare di piu'? 

 prescindere da cosa possa dire la legge a riguardo, sia un'immensa cazzata.
mi pare molto piů cazzata avere il db accessibile senza i dovuti criteri 
di sicurezza, a prescindere che contenga numeri di carte di credito in 
chiaro o criptate.

 tutti gli operatori telefonici nei propri DB.
visto il gran numero di spettatori non ne dubito che ce ne sia l'esigenza.

 credito in chiaro o criptate.
Perche' una cosa esclude l'altra? ;)
-- 
Senti, se abbiamo un culo, non significa che qualcuno deve per forza 
metterci qualcosa dentro.
                                                   Bodhi

 cazzata.
Partiamo dal presupposto che avere i numeri delle carte nel db e' una grossa 
cazzata ...
  ngw
-- 
"ma gavte la nata." -- Jacopo Belbo
http://www.tochunky.org

 Perche' una cosa esclude l'altra? ;)
no, ma c'è un'ordine di priorità.
questi dati particolarmente sensibili prima si dispongono in un db a 
parte opportunamente messo in sicurezza, poi si ragiona come cifrarlo.
il pan delle cc non è come le password di cui ti basta memorizzare un 
hash, ti serve chiaramente di tornare indietro al valore originale. 
ovvero il programma che ci accede deve avere la chiave di decodifica e 
se non impedisci fisicamente l'accesso ai potenziali malintenzionati 
devi mettere in conto che può essere intercettata. se tu hai il pan allo 
stesso livello di accesso delle (ad esempio) transazioni a cui accede 
anche il datawarehouse per le statistiche, potenzialmente sei a rischio 
elevato anche se i pan sono criptati.

FabioT wrote:
: Per quanto riguarda le carte di credito, non conosco la
: regolamentazione attuale, ma fino a qualche anno fa non era
: neanche possibile memorizzarle (criptate o no).
Sei sicuro? Ci si pagano le bollette con le carte di credito.
Da qualche parte devono sta scriti i numeri nei db degli esercenti.

Marcoxxx wrote:
:: AleTV ha scritto:
::
::: E adesso vienimi a dire che implementare la
::: criptazione/decriptazione di questi dati aumenta lo sviluppo del
::: prodotto del doppio...
::: Ciao, Alessandro
::
:: Dipende cosa intendi con "aumenta lo sviluppo del prodotto del
:: doppio" Prova ad andare in Ericsson e chiedergli quanto valutano il
:: costo orario di una persona che lavora sulla cifratura dei database
:: di Tim/Telecom.
Perchè, i db di telecom sono cifrati?

Marcoxxx wrote:
:: Roberto C. ha scritto:
::
:: [SNIP]
::: Non ho capito, c'è una legge che obbliga a criptare i numeri di
::: carta di credito nel db?
::
:: Voglio proprio sperare di si.
:: Addirittura l'imsi delle SIM Card ormai viene criptato praticamente
:: da tutti gli operatori telefonici nei propri DB. Spero proprio che
:: valga anche per i numeri delle carte di credito.
Si si, criptato quando viene memorizzato, trasmesso in chiaro sul wire di 
rete quando da remoto il client accede e fa "select codice_simcard from 
simcardtable", che Ipsec era troppo complicato :-)
Saluti.

):

Sicuro, non nel DB dell'ecommerce di turno.
Che usi BancaSella o qualcosa di simile, le carte di credito vanno gestite 
dalle _banche_, non dai negozi.


 Da qualche parte devono sta scriti i numeri nei db degli esercenti.
ma asslutamente no.
chiedono l'autorizzazione all'addebito e poi usano quello per le 
successive transazioni, un po' come i rid.

 deve pagare necessariamente il doppio.
seguendo il tuo ragionamento, se a tuo giudizio il cliente paga poco 
quei dati potrebbero anche finire in un ftp pubblico o su emule. giusto?

ngw wrote:
:: Partiamo dal presupposto che avere i numeri delle carte nel db e'
:: una grossa cazzata ...
Uh uh, allora grossa casa di software USA (non M$) che vende grosso prodotto 
di ecommerce fa grossa cazzata.

ngw wrote:
:: Sicuro, non nel DB dell'ecommerce di turno.
:: Che usi BancaSella o qualcosa di simile, le carte di credito vanno
:: gestite dalle _banche_, non dai negozi.
Allora ti avviso che TIm e Telecom hanno nei loro DB  i numeri delle carte 
di credito usata dai clienti per pagare le bollette.
Saluti.

rootkit wrote:
:: GdG ha scritto:

Dipende.
Siccome che non esiste una legge che lo impedisce molti memorizzano il 
numero della carta di credito
del cliente.

GdG ha scritto:

non c'è una legislazione che lo impedisce, però è una menata inutile 
visto c'è chi offre questi servizi.

 La mia etica professionale non mi fa fare una piega: 
etica professionale?? ma non farmi ridere.
appena un messaggio fa scrivevi: "Dico semplicemente che anche queste 
accortezze banali, a livello di sicurezza dei dati, possono non venir 
adottate *volontariamente* se il cliente paga poco"
trattasi di un disegno criminale, se non ne sei convinto leggiti 
all'art. 43 del codice penale la definizione di dolo. che poi tu sei 
convinto di passarla liscia ciò non toglie che ragioni come un inetto 
delinquente.

 informatica.
ma tu sei in malafede perchè, ripeto, dichiari di non adottare 
*volontariamente* le accortezze banali sulla sicurezza dati.

 cazzata ...
Se non vuoi costringere l'utente ad inserire il numero ogni volta (e non
importa cosa TU pensi che l'utente dovrebbe fare, il 99% degli utenti
si incazza), il numero lo devi tenere nel db, non ci sono santi. Che fai
altrimenti, tieni un librone con uno schiavo che va continuamente a leggere
ogni volta che c'e' una transazione?

 ciò e le limitazioni di responsabilità.  
That's ok, finché il cliente non decide di rivolgersi a un avvocato (o,
peggio, è avvocato lui stesso) e di farti il deretano. Le mie memorie
di diritto mi dicono che se una azione o una clausola sono palesemente
contro il diritto (Codice Cibile) o la dottrina (sentenze della
Cassazione), qualunque scarico di responsabilità equivale grossomodo a
carta igienica.
L'unica cosa per cui 'stte cose esistono è dovuta al fatto che, stanti
i tempi biblici della giustizia civile in Italia, a nessuno viene in
mente di intentare un procedimento giudiziario (le cui spese, fino a
sentenza, vanno pagate di tasca).
-- 
Ciao!
Luca

 visto c'č chi offre questi servizi.
Non e' una menata inutile visto che, da quanto ricordo, chi offre
"questi servizi" si fa pagare parecchio di piu' degli altri che
fanno semplicemente intermediazione di addebito. 

 di Euro sul tavolo quasi facendoti un favore?
insisti pure su questo concetto della tariffa bassa.
se nel contratto è stabilito il compenso e questo compenso non ti
stava bene, perchè hai firmato il contratto?
se non ti trovi daccordo con il compenso perchè fai il lavoro?

Luca Menegotto wrote:
:: Osid wrote:
::
::: Dove sarebbe il dolo? Le specifiche del sistema software prevedono
::: la memorizzazione dei dati della CdC. Il cliente firma per
::: accettazione ciò e le limitazioni di responsabilità.
::
::
:: That's ok, finché il cliente non decide di rivolgersi a un avvocato
:: (o, peggio, è avvocato lui stesso) e di farti il deretano. Le mie
:: memorie di diritto mi dicono che se una azione o una clausola sono
:: palesemente contro il diritto (Codice Cibile) o la dottrina
:: (sentenze della Cassazione), qualunque scarico di responsabilità
:: equivale grossomodo a carta igienica.
Al limite se sono contrarie alla legge (non al diritto). La giurisprudenza 
(le sentenze)
può aiutare se ci sono dubbi sull'interpretazione della norma nella 
particolare fattispecie.
Quindi tutte le altre porcate (clausole vessatorie) NON contrarie alla legge 
e se esplitamente approvate dalle parti sono legge per quest'ultime.
Saluti.