venerdì 20 giugno 2008
Sono daccordo con il recente post di Mauro e quindi con l'affermazione di Tommaso: "Se non è semplice c'è qualcosa che non va". Questa è stata la mia impressione in diversi lavori che ho visto, ma qui prepotentemente si insinua un altro problema: le performance.
Si, abbiamo macchine da 4GHz, ma certe scelte costano care anche su macchine superveloci.
Si, entro 5 anni arriveremo a 80 core, dice Intel (poi quando parlavo dei 16 core mi davano del visionario), ma sfruttarli per bene non è affatto semplice e gli strumenti sono ancora pochi (tra l'altro questi saranno proprio gli argomenti di una delle mie sessioni ai Community Days).
Ma ...
Ma recentemente ho toccato con mano che alcune scelte architetturali costano in performance e sono di tangibile fastidio all'utente che usa l'applicazione.
Factory, Proxy, MVC, MVP, Adapters, ... sono fantastiche soluzioni by design ... se si chiamano pattern significa proprio che sono stati usati con successo da migliaia di developer e quindi su questo non si discute. Il problema è chi li usa 
.
- La prima considerazione è che il disegno dell'applicazione è e rimarrà un passo fondamentale per la creazione di una applicazione, e che quegli strumenti sono validissimi.
- La seconda considerazione è che lo sviluppatore e l'architetto devono dialogare per capire fin dalla stesura dell'architettura per capire quali possano essere i colli di bottiglia e non finire col piangere davanti ad un profiler.
- La terza considerazione è che le performance vanno misurate perché è troppo facile dare la colpa al mancato uso di StringBuilder o all'architetto eccentrico, ma devo ribadire che se alla performance non ci si pensa fin dall'inizio, alla fine si fa prima a riscrivere, il che è quanto di peggio possa accadere.
- La quarta considerazione è che i problemi di performance dovuti all'architettura ci sono a prescindere dall'ambiente di sviluppo e possono accadere anche con la programmazione nativa in C++. Solo che chi programma in C++ non ha strumenti insiti nel linguaggio per componentizzare (i componenti ci sono se si usa COM, Corba, Framework, ...) e quindi tipicamente l'architettura è più spartana.
- Infine quello che ritengo sarà la soluzione ottimale e il miglior compromesso: la generazione di codice. Alcune scelte architetturali sono legate all'uso di tecnologie come Reflection, potenti ma anche arma a doppio taglio.
Concludendo, non sempre fare i "perfettini" con l'architettura paga, anzi tutt'altro.
Quindi tornando al post di Mauro aggiungo che l'architettura non deve essere solo semplice ma anche un compromesso con le tecnologie e i linguaggi che si stanno utilizzando. Non credo alla pura architettura riusabile meno che mai in modo trasversale sul Framework, su Java, su COM, etc. L'architettura si deve 'sporcare', quando è necessario, perché il nostro è il regno della tecnocrazia.
Paragone con un algoritmo di calcolo: lo scrivo in C++ e lo traduco in C# (o viceversa).
Funziona? Si. È efficicente? No, nella gran maggioranza dei casi perché lo strumento ha delle differenze notevoli da cui non possiamo prescindere.
mercoledì 18 giugno 2008
Chi fa il docente di corsi sa bene che possono capitare le cose più strane, ma questa ci ha fatto ribaltare tutti dalle risate.
Dite che fa parte del LAB?
Ovviamente come prima cosa ho ruotato fisicamente il monitor, poi ho optato per una soluzione più high-tech 
Grazie alla simpaticissima Veruska per le risate 
BTW l'utility della scheda grafica Intel lascia di default gli shortcut di rotazione monitor attivi.
venerdì 13 giugno 2008
domenica 8 giugno 2008
Nella sicurezza informatica i due attori sotto i riflettori sono l'attacker e il defender. Il dato più evidente è che l'attacker è sempre costantemente in vantaggio perché può inventare sistemi e modalità di attacco che non sono ancora noti al defender.
Il sistema sicurezza evolve in una sorta di spirale; man mano che un sistema informatico diventa più sicuro, gli attacchi mutano, evolvono per qualità e inventiva, e le contromisure per contrastarli sono dei veri contanti che gli utenti incassano come sicurezza di qualità ancora superiore. E naturalmente il ciclo continua all'infinito.
Questa continua elevazione della sicurezza non raggiunge un livello soddisfacente a causa di un grosso e grave difetto: sto parlando dell'utente.
L'utente è un fattore primario nella sicurezza ed ha un peso importante tanto quanto le scelte tecnologiche e architetturali. Gli attacchi di social engineering lo dimostrano rendendo spesso vane le barriere tecnologiche più sofisticate.
Poco dopo l'invenzione dell'automobile, sulle strade si verificarono i primi tragici incidenti e si decise che era indispensabile l'introduzione di una patente prima di poter scorazzare per le strade armati di motore a scoppio. L'utente inesperto è dannoso per gli altri? La risposta è si e la piaga dello spam si allarga proprio per questo motivo.
Nel 1630 gli untori dell'epidemia di peste venivano linciati o, nella migliore delle ipotesi, processati.
Ogni utente che lascia esposto ad internet il PC non aggiornato, con servizi aperti, senza firewall, e apre gli attachment delle email facendosi impestare di virus è un untore di nuova generazione. Si perché al contrario di quanto si crede comunemente i virus si contrastano meglio con l'intelligenza e la conoscenza del PC rispetto all'uso dello stupido, e talvolta persino inutile, antivirus.
Perciò quando vedo un'iniziativa come quella di www.SicurezzainRete7x24.org non posso che essere contento.
Rendiamo l'utente consapevole di come usa il suo PC e non riduciamo gli utenti a degli automi che affidano la sicurezza solo allo strumento che hanno davanti ai loro occhi.
La settimana della sicurezza in rete è appena iniziata e l'iniziativa è rivolta agli utenti finali. Ovviamente non finirà il 14 Giugno ma questa settimana è una buona occasione per i professionisti del settore per promuovere l'iniziativa verso i propri familiari, amici e clienti.
Tra le video interviste ci sono quelle di Vincenzo di Russo, il guru di Internet Explorer, ed il sottoscritto.
Infine un paradosso: è curioso che i cosiddetti meno esperti, proprio perché fanno numero, sono la principale causa scatenante di quell'evoluzione tecnologica (hardware più potente e meno costoso, banda internet più ampia, applicativi più sofisticati, games più realistici, etc.) che al tempo stesso temono e vorrebbero che fosse meno rapida. Nel contempo i "geek" vorrebbero godersi più novità tecnologiche possibili ma senza quegli utenti che invece l'hanno resa possibile.
lunedì 26 maggio 2008
Outlook Express non mi dispiaceva affatto. Tutto sommato ho postato per anni migliaia di messaggi su diverse gerarchie senza avere troppi problemi.
Da quando ho aggiornato il mio PC a Windows 2008 e più recentemente anche sul nuovo portatile (ebbene si, ho ceduto all'offerta Dell, un XPS 1530) mi sono trovato forzatamente ad usare Windows Mail su cui funziona ancora il caro vecchio OE-Quotefix.
Anche se all'apparenza sembra identico al vecchio Outlook Express, sono riusciti a fare il disastro. Quando apro un gruppo seleziona automaticamente il primo messaggio non letto, marcandolo come letto. All'apertura di un gruppo "corposo" flickera la lista dei messaggi per diversi secondi. Nessuna nuova feature per gestire decentemente i messaggi.
Risultato: bruciato Windows Mail e migrazione immediata e definitiva al già testato MesNews. Tutti i problemi risolti e opzioni comodissime a bizzeffe (sync più veloce, quoting, fonts, opzioni dei server, ...). Sono bastati solo pochi post per rendermi conto di essere molto più produttivo e in grado di postare di più in meno tempo.
L'impressione personale è che come accadde per IE6 (cioè messo in cantina per troppo tempo dormendo sugli allori) anche per Outlook Express sia accaduto lo stesso, con la grossa differenza che a MS non stanno simpatici i newsgroup (vedi tempi di latenza sul post e tante altre cose che vado ripetendo al limite dello scontro fisico ad ogni incontro con i team di MSDN Forums).
Peccato veramente perché NNTP è un pilastro di Internet. Vedremo che succede, ma se non ci pensa MS stiamo sicuri che ci penseranno altri.
Stavo cercando cosa offre di buono il mercato dei CMS su piattaforma Asp.net e Davide mi ha indirizzato su Sitefinity, il CMS della Telerik
La piattaforma mi è piaciuta perché lascia molte porte aperte allo sviluppatore che voglia estendere la struttura base e mi è caduto subito l'occhio all'offerta per la versione full (chiamata "standard") per gli User Group associati ad INETA che include tra l'altro anche l'hosting (cosa non proprio da poco):
http://www.sitefinity.com/product/features/free-offer.aspx
Non c'è che dire, un ottimo startup per nuovi User Group!
sabato 17 maggio 2008
Stando alla knowledge base di Debian un programmatore ha avuto la bella idea di togliere due righe di codice che hanno reso predicibile la generazione di numeri casuali, che sono la base per gli algoritmi crittografici. (Crediti a Luciano Bello che ha trovato il bug e Obiwan per avermelo segnalato).
Cosa ha provocato e provocherà questo bug?
- Tutti i certificati generati con OpenSSL a partire dalla versione 0.9.8c-1 (del 17 Settembre 2006 !!!) su un OS basato su Debian sono craccabili e DEVONO essere rigenerati.
- Tutte le chiavi di SSH, OpenVPN, DNSSec, qualsiasi certificato X.509 e chiavi di sessione per connessioni SSL/TLS sono compromesse.
- Tutti i certificati Verisign come da questo bollettino, devono essere sostituiti in quanto compromessi
Questo significa che la patch di Debian NON risolve totalmente il problema in quanto tutte le chiavi ed i certificati che sono stati generati con la versione bacata sono ormai compromessi.
La causa del bug probabilmente sta nel fatto che qualcuno ha modificato del codice senza poi siano stati fatti la review di sicurezza su quel codice, cosa che avrebbe in tutta probabilità portato alla luce il problema.
Si, sto dicendo che applicando SDL nel modo corretto questo bug non sarebbe passato.
* * *
Ok, ma quanto è sfruttabile il bug? Semplicissimo, basta usare questi tool e il crack è pronto. Inutile nasconderli, security through obscurity NON funziona, se ancora ci fosse bisogno di dirlo.
Questo feroce bug colpisce non solo Debian e le distro derivate come Ubuntu, ma tutti quei sistemi embedded che sono basati su Debian. Pensiamo a telecamere IP, centralini, router, access point, etc. Si, perché Debian è una delle distro più usate in apparati embedded.
La vera domanda perciò è: quanto tempo occorrerà adesso per aggiornare tutti questi sistemi? Probabilmente infinito perché tipicamente i sistemi embedded non vengono MAI aggiornati dopo la loro produzione. Questo deve far riflettere e cominciare a far cambiare la mentalità nel software per cui un sistema non aggiornato è MORTO.
Diamo infine un caloroso benvenuto a Debian nel mondo reale, fatto di persone umane che sbagliano a prescindere dalla bandiera dell'OS a cui stanno lavorando. La sicurezza è un problema di tutti, nessuno escluso. Già perché personalmente non penso che sia affatto scandaloso trovare un bug di sicurezza, il vero scandalo è che molti pensavano che questo non accada sulle distro Linux e meno che mai in Debian.
Come nota finale non posso che definire sconcertante uno dei commenti iniziali a questo post di Larry Osterman che respinge la tesi che sia un bug di Debian. Quando si dice talebano ...
mercoledì 14 maggio 2008
Per qualche strano motivo Microsoft non concepisce il fatto che qualcuno come il sottoscritto preferisca lavorare su versioni server del sistema operativo.
In passato ho usato Windows 2000 server, poi 2003 e attualmente 2008 che ho sia sul portatile che sul desktop e i vantaggi per uno sviluppatore sono tanti: dhcp e dns per le macchine virtuali, IIS versione server, terminal services per sviluppare in roaming per l'ufficio o da una vpn, etc.. Usando Win2008 come workstation ho abilitato i temi di Vista, aero, e tutte le altre comodità.
Purtroppo però non è abilitabile il bluetooth sul portatile ma mni basta che il power management funzioni a meraviglia.
Come software tutto ok tranne la serie "Live" dei software che proprio di installarsi su Windows Server non ne vuole sapere. Niente Live Messenger e qualche trick per Live Writer.
Questo mi solleva un montagna di dubbi a livello di sicurezza: Il mio Windows Live Messenger mi segnala di essere obsoleto ma il setup di Live Messenger non può essere eseguito.
Che devo fare? Disinstallare MSN perché è a rischio? Sappiamo bene che MSN è una applicazione fortemente a rischio ad attacchi e mantenere installata una versioine obsoleta è senza dubbio un chiaro ed evidente rischio di sicurezza.
Io credo fermamente che Microsoft dovrebbe rivedere il "profilo" degli utenti tipici di Windows prevedendo che un utente avanzato possa prediligere Windows 2008 a Vista senza per questo negargli nessun tipo di funzionalità, e perché no, anche i games.
martedì 22 aprile 2008
Ancora una volta un Summit magnifico. A prescindere dall'aspetto tecnologico, un po' tutti abbiamo apprezzato la qualità della vita (in termine di vita quotidiana, cortesia e vivibilità) di Seattle e dintorni. Questo è qualcosa che non si può descrivere con parole, ma va vissuto in prima persona ed è l'aspetto che lascia dei ricordi molto piacevoli.
Ma l'aspetto tecnologico non è stato da meno. Ho passato il mio tempo al Campus a parlare di tre argomenti principali:
- Developer Security. Novità dal gruppo SDL, evoluzione nel threat modeling, futuro. CLR e Silverlight security.
- VC++ vNext. Grosse novità in vista, enormi quantità di feedback a 360 gradi su tutto il prodotto. Altrettanto grande considerazione e apprezzamento da parte del team sul feedback ricevuto. Stay tuned ...
- MSDN Forums vs NNTP. Ancora mezz'ora prima di andare in areoporto ero in un meeting con il team che si occupa di questi temi. I punti su cui ho ripetutamente insistito (quasi in modo molesto :) ) sono stati:
a) NNTP è "solo"un protocollo al pari diHTTP e che NNTP non preclude di veicolare un rich content
b) NNTP può essere esteso al pari di NNTP
c) le caratteristiche che oggi offre NNTP sono ottimali per chi partecipa in modo attivo alle discussioni tecniche
d) UGIdotNET e Aspitalia sono perfetti case studies di erogazione dello stesso contenuto con protocolli differenti.
Posso solo garantire che questi messaggi sono arrivati a chi di dovere. Stay tuned ...
Visual Studio box, Visual C++ Art e Ale Contenti nel suo ufficio a sorvegliare le Safe CRT :-). Ale you promised ... open your own blog! ;-)
Ecco i Developer Security MVP deliziati da una fantastica sessione di Shawn Farkas (terzo da sinistra) sulla sicurezza in Silverlight.
In piedi Herb Sutter partecipa alla discussione su Visual C++ e al feedback degli MVP.
martedì 15 aprile 2008
Dopo il primo giorno di splendido sole (26 gradi!) a base di amici e barbeque in quel di Kirkland (grazie Max!!!) ...
... oggi è partito il Summit 2008 che vede il cambio del vertice MVP dal grandissimo Sean O'Driscoll a Toby Richards
Sean si dedicherà d'ora in poi ad un mestiere che probabilmente in Italia verrà compreso tra parecchi anni, consulenza sul social media e communities. Un argomento che non tocca solo le community che orbitano nell'industria IT ma di qualsiasi azienda che abbia a che fare con gli end-user. Il mondo del web sta rivoluzionando il rapporto tra gli utenti (vedi facebook.com) e tra gli utenti e le aziende e lui certamente in questi anni ha potuto sviscerare come pochi altri questo argomento.
La giornata è servita soprattutto a incontrare di persona le tante persone che sentiamo durante l'anno ma che si ha ovviamente poche occasioni per incontrarle se non in conferenze o qui a Seattle.
Io ho dedicato il resto della giornata a difendere a spada tratta le community per far si che i protocolli NNTP (ms newgroups) e HTTP (msdn forums) attingano ad uno storage comune separando invece le UI (browser e newsreader, ma non solo) per soddisfare le esigenze di chi fa domande, di chi da risposte e delle comunity che vogliano aggregare (mashup) questi contenuti. I "miei" case studies sono stati UGIdotNET e Aspitalia.... che gli MVP portino consiglio 
.
Domani giornata piena... io sarò tra i dev-security e il team di VC++.
lunedì 14 aprile 2008
Il viaggio in aereo (a destra la groenlandia):
Il tradizionale viaggio in Limo a downtown ...
check-in in albergo e subito a Cheescake factory insieme al grande Ale Contenti (Lead PM librerie di VC++)
Questi si che sono hamburger:
sabato 12 aprile 2008
Non sono bastate le 118 vittime dell'8 Ottobre 2001. Negli ultimi due giorno il radar di terra non funzionava. Chissà da quanto tempo non funzionava. I viaggiatori l'anno scoperto con il brutto tempo perché non era possibile l'atterraggio a vista.
Il risultato della nostra personale esperienza è stato:
- passeggeri dirottati su Malpensa con i loro propri mezzi. Noi abbiamo speso in quattro 170 Euro di taxi che ha violato ogni legge della fisica per portarci in tempo a Malpensa
- prenotazione e check-in online (con tanto di posti assegnati) tutti annullati
- nuovo check-in a Malpensa con i minuti contati e riassegnazione casuale dei posti
- alcuni di noi dirottati su Milano - Londra - Los Angeles - Seattle che non è ancora giunto a destinazione mentre sto scrivendo
- altri tra quelli arrivati ieri sera con il bagaglio perso
Un pensiero va ai 118 di quel tragico volo del 2001 e ringrazio il cielo (non certo la SEA) di essere arrivato in un modo o nell'altro qui a Seattle.
L'arrabbiatura è all'ennesima potenza perché come professionisti informatici spendiamo tantissimo tempo a progettare e realizzare sistemi che prevedano ridondanza, gestione delle eccezioni, etc.
Si, ci sono tantissime piccole aziendine che sono molto più efficienti di un vitale sistema di sicurezza areoportuale e questo è un vero inaccettabile schifo.
- Non è accettabile che non ci sia una ridondanza per un radar di terra
- Non è accettabile che non ci sia un tecnico in grado di metterci mano in tempo reale, giorno, notte, domenica o natale che sia.
- Non è accettabile che in caso di imprevisto NON esista una benché minima procedura per risolvere diversamente la soluzione
Queste cose non sono la luna, sono la normalità per l'industria IT ed elettronica. Vergogna SEA, vergogna Linate.
mercoledì 9 aprile 2008
Quest'anno si che ho le idee chiare per le elezioni politiche. Anche il test me lo conferma .
Quindi ho taroccato il test per renderlo più geekkoso ed ecco comparire la mia reale preferenza:
Nel bagaglio decine tra caricatori cavetti e adattatori vari. Venerdi mattina la carovana di MVP viaggerà per il fantastico MVP Summit 2008.
Limitatamente a quanto è permesso dall'NDA, cercherò di bloggare quanto più è possibile.
Ritorno previsto il 18 Aprile. E da Seattle a Segrattle, il 21 e 22 Aprile sarò in Microsoft a Milano a tenere il primo corso su Office Open XML.
mercoledì 2 aprile 2008
Oggi si è conclusa la lunga battaglia combattuta in vari paesi mondiali tra i sostenitori e i detrattori delle specifiche Office OpenXML che oggi sono divenute finalmente standard ISO DIS 29500:
http://www.reuters.com/article/technologyNews/idUSL0179716920080401
http://www.microsoft.com/presspass/press/2008/apr08/04-01OpenXMLVotePR.mspx
In sede ISO (mondiale) i commenti propositivi ci sono stati, e sono stati tanti. Nonostante questo mi è spiaciuto vedere spesso una battaglia troppo politica e troppo poco tecnica, con abbondanza di "no" aprioristici invece di controproposte concrete che avrebbero solo potuto migliorare il risultato finale.
Perché credo che questo standard sia un vantaggio per tutti?
- L'approvazione di uno standard non afferma alcuna prevalenza sul mercato ma toglie al produttore la libertà di giocare con le specifiche. La presenza di due standard (ODF e OOXML) toglie qualsiasi dubbio sul fatto che possano avvantaggiarsi solo per il fatto di essere standard ISO.
- Microsoft ha un indiscutibile vantaggio sul mercato con Microsoft Office. Da oggi abbiamo la garanzia che il formato non potrà cambiare in modo significativo e siamo, sia come sviluppatori che come utenti finali, garantiti dallo standard ECMA e ISO che gli investimenti su quel formato siano a lungo termine.
Se viceversa Microsoft avesse deciso di tenere un formato proprietario, proprio perché possiede la fetta di mercato più grossa, avrebbe potuto fare il bello e il cattivo tempo, minando seriamente gli investimenti di software house e utenti finali.
- La durata nel tempo delle informazioni. La RAI periodicamente travasa i filmati di tutto il suo storico da un media all'altro per mantenere "viva" l'informazione che, anche quando è digitale, è molto lontana dall'essere immortale. Io stesso ho ancora vecchi file in Word per DOS, Wordstar, Paintbrush, Lotus 123, Framework (Ashton Tate), etc. che sono "morti".
Un formato digitale deve essere facilmente fruibile in modo indipendente dal sistema operativo e dalle tecnologie usate per sviluppare le applicazioni. Il formato zip e XML garantiscono questa sopravvivenza alle tecnologie.
- La retrocompatibilità. È indiscutibile che la retrocompatibilità giochi per gli utenti un ruolo fondamentale. Non potremmo mai chiedere, come sviluppatori, di migrare un qualsiasi formato ad uno nuovo che non supporti la totalità delle caratteristiche del formato precedente. Questo è accaduto nel passaggio da Lotus 123 a Excel e vale tutt'ora per una moltitudine di formati come ad esempio TGA.
Questo è stato certamente il punto fondamentale per cui non ho aderito all'idea di poter adottare solo ODF che unico standard. Siamo pieni di multi-standard su tantissime tecnologie, lo scopo primario di uno standard NON è quello di essere unico, ma di garantire la condivisione delle specifiche tra gli implementatori.
- Le specifiche OOXML sono aperte e libere (al momento già reperibili sul sito ECMA). Tanto per fare un paragone illustre, JPG è una specifica chiusa e disponibile solo a pagamento.
Alla faccia delle specifiche troppo grosse, ad oggi sono in grado di produrre documenti OOXML di wordprocessing e spreadsheet che ho testato con Word, Excel e OpenOffice. Si perché il plugin free di Microsoft per le precedenti versioni di Office funziona anche aprendo il formato OOXML da OpenOffice. Grazie al "si" di oggi, so che il tempo investito a scrivere questo codice è stato ben riposto.
E dopo cosa viene? Spero che da oggi si inizi a parlare solo della parte tecnica e migliorare lo standard per le prossime versioni. Gli standard non sono statici, vivono e si evolvono e la giornata di oggi è solo l'inizio.
lunedì 31 marzo 2008
L'orologio al quarzo ha rivoluzionato una decade e l'introduzione degli orologi radiocontrollati prometterebbe una nuova rivoluzione....
Mi oppongo! Il caro vecchio orologio con ora "relativa" cioè senza sincronizzazione automatica è una garanzia senza rivali.
La prima possibilità (che mi è successa veramente qualche anno fa) è che il segnale venga capito "male" dall'orologio che cambia l'ora in modo assurdo, magari di 12 ore più indietro. Dopo questa esperienza ho capito che mai e poi mai avrei dovuto usare una sveglia radiocontrollata. Il vecchio orologio al massimo sballa di qualche minuto ma non fa alcun danno.
La seconda mi è venuta in mente oggi e non dubito che qualcuno ci abbia già pensato.... un bel attacco di hacking sugli orologi. Costruisco un trasmettitore radio e mando un segnale di sincronia radio, sballando totalmente gli orologi a portata di antenna. Vi immaginate il disastro di un attacco di questo genere? Magari eseguito durante la notte.
Perciò va bene avere un orologio per sincronizzare gli altri a mano, ma non ci affiderei nessun servizio essenziale, a partire dalla sveglia di casa.
giovedì 27 marzo 2008
A causa di un driver sballato (che novità, eh ...) che cerca di pilotare il monitor ad una risoluzione diversa da quella del pannello di controllo, ho deciso il cambio di scheda grafica.
Comincio a sospettare che ATI e nVidia facciamo marketing producendo cattivi driver, ma lasciamo perdere.
Non volendo rumorose ventole, ecco il mostro che mi sono trovato davanti all'apertura della scatola (notare il cavo supplementare di alimentazione). Lì per lì ho pensato che la marca fosse Whirlpool .
La tecnologia va avanti e i signori Joule e Maxwell ci guardano dall'alto, ridacchiando...
Chiamarli pirati è fargli un complimento e la triste realtà non sono tanto loro che ci provano, ma quelli che ci cascano.
In questo attacco, fresco fresco di questa notte non c'è nulla di speciale, è una delle solite email che arrivano regolarmente.
Punto A: Email sgrammaticata ... dovrebbe almeno insospettire
Punto B: Hyperlink palesemente errato
Punto C: Il vero sito usa https e l'utente può vedere il lucchetto
Punto D: L'indirizzo del sito clonato è palesemente errato
Veniamo però ai punto dove la banca avrebbe potuto fare meglio:
- Il nome del sito è totalmente anti-intuitivo. Se fosse stato il vero nome della banca e con un URL semplice (io lo chiamo ergonomico) l'utente avrebbe meno dubbi a scegliere quello giusto.
Da notare che spesso in questi attacchi vengono usati URL molto simili a quelli orginali come www.mia-banca.it oppure www.miabanca.me.com, etc.
Questo è il motivo per cui è importante il punto 2. - Il vero sito purtroppo NON fa uso di certificati Extended Validation che avrebbero trasformato la barra di Internet Explorer con un background verde e rendendo molto più evidente l'affidabilità del sito.
Questi certificati vengono rilasciati solo dopo verifica dell'esistenza fisica dell'azienda richiedente e costano molto più cari. - Il sito non fa uso di rolling-codes che vengono generati sempre diversi per ogni accesso e non riutilizzabili, rendendo così inutile il furto delle password.
Non sono stato a guardare i sorgenti della pagina per eventuali altre cose.
A coloro che pensano che gli utenti non possono essere anche "meccanici" del proprio veicolo rispondo che a mio avviso l'utente dovrebbe almeno prendere una patente prima di avventurarsi per la strada.
La truffa internet è più facile da prevenire rispetto al furto del numero della carta di credito in qualsiasi negozio, la differenza come al solito la fa l'utente e non il mezzo.
domenica 23 marzo 2008
Ho finalmente concluso la riscrittura completa di una generica implementazione di IXmlSerializable.
Ovviamente per essere generica usa reflection e non ho fatto l'ottimizzazione dell'implementazione di default, cioè la generazione al volo con CodeDom del codice per serializzare/deserializzare, in quanto per i progetti in cui mi serve la performance di questo codice non è, al momento, critica. In più ci sono già voluti alcuni giorni per considerare tutti i casi imposti dagli attributi XmlElement, XmlChoice, XmlArray, etc. etc.
Perché rifarla da zero? Perché abbiamo bisogno di due cose:
- Avere un evento nella entity prima e dopo la serializzazione (cosa non banale quando la entity è in mezzo ad un mare di oggetti dentro un domain model).
- Poter modificare liberamente il risultato della serializzazione senza dover riscrivere ad-hoc il codice per ogni singola entity (lavoro massacrante).
Purtroppo riscrivere un XmlWriter non aiuta in modo granulare e così via alla riscrittura. Adesso ogni entity riceve, se vuole, un evento con un XDocument (superbo modo di gestire XML) che può modificare come più gli piace dopo la serializzazione e prima della deserializzazione.
Durante le varie manipolazioni con Reflection ho incontrato una piccola stranezza. Quando chiamo GetProperties l'array delle proprietà viene restituito in modo comodo a chi l'ha implementato, ma anche in modo "illogico".
La lista infatti è in ordine di dichiarazione della classe ma nella gerarchia sono elencate le proprietà a partire dalla classe in questione a scendere verso quella base.
Il serializzatore XML di default invece (a meno di non specificare un Order preciso) serializza dalla base risalendo la gerarchia, cosa che appare logica visto che una classe derivata "specializza" e quindi di fatto aggiunge delle proprietà alle classi di base.
Da qui il listato che segue, probabilmente ancora ottimizzabile ma perfetto per il mio scopo. Ovviamente fare il reverse delle proprietà non andrebbe bene perché il loro ordine è corretto per ogni livello della gerarchia di derivazione.
1: /// <summary>
2: /// Same as Type.GetProperties, but returning properties in the correct order
3: /// The problem is that Type.GetProperties returns derived properties first,
4: /// while the XML Serializer want the base properties first.
5: /// </summary>
6: /// <param name="t"></param>
7: /// <returns></returns>
8: private PropertyInfo[] GetProperties(Type t)
9: {
10: //PropertyInfo[] properties = t.GetProperties(
11: // BindingFlags.GetProperty | BindingFlags.Instance | BindingFlags.Public);
12:
13: List<PropertyInfo> props = new List<PropertyInfo>();
14: List<Type> types = new List<Type>();
15: // Take the list of all base types
16: do
17: {
18: types.Add(t);
19: t = t.BaseType;
20: }
21: while(t != typeof(object));
22: // invert the type list.
23: // After this the list start from the base types to the derived ones
24: types.Reverse();
25:
26: foreach(Type x in types)
27: {
28: // for each type in the list, I take only the public properties
29: // It's foundamental to get only the properties declared in that level
30: // by using "DeclaredOnly" binding flag.
31: PropertyInfo[] properties = x.GetProperties(
32: BindingFlags.GetProperty | BindingFlags.Instance |
33: BindingFlags.Public | BindingFlags.DeclaredOnly);
34: props.AddRange(properties);
35: }
36: // finally I can return the PropertyInfo array
37: return props.ToArray<PropertyInfo>();
38: }
Sto anche pensando di pubblicare la serializzazione XML su Codeplex, ma non so se sarebbe di interesse...
lunedì 17 marzo 2008
Poco fa ho ricevuto una email che non posso che riportare testualmente:
I just wanted to let you know the smashing success of the Fish Bowl video you recorded in Barcelona. Your video—posted to www.virtualteched.com on February 6—Threat Modeling and Discovering Security Issues came in near the top of our February Video Viewings Metrics with 350 hits…great job!
Il link al video è: http://www.virtualteched.com/pages/videossearch.aspx?KW=raffaele
E chi ha mai detto che la security è noiosa?
A parte la soddisfazione personale, questo è un chiaro segnale che l'argomento sicurezza e il Threat Modeling che ho trattato nel video è certamente un argomento sempre più sentito e che non è più ignorabile.
Forza allora ... security first!
venerdì 14 marzo 2008
La cronaca di oggi riporta due attacchi informatici stra-prevedibili, tanto che io e Max ne parliamo ormai da anni.
Il primo, da quanto leggo nell'articolo, sembra essere lo sniffing delle password i cui hash passano nei pacchetti SMB della rete bancaria. http://www.tg5.mediaset.it/cronaca/articoli/2008/03/articolo6353.shtml
Dall'articolo capisco che qualcuno ha installato un piccolo apparato alla rete fisica della banca raggiungibile tramite wifi dall'esterno della banca.
Il secondo è la falsificazione del fingerprint.
http://www.video.mediaset.it/video.html?sito=studioaperto&data=2008/03/14&id=35928&categoria=edizione/servizio&from=studioaperto
Di fantasia ce n'è voluta proprio poca. Il sistema è fin troppo facilmente ingannabile.
Si da il caso che alla scorsa WPC a Milano io e Max abbiamo spiegato e mostrato demo anche su questi attacchi:
- In una delle tante demo ho usato un minuscolo access point per catturare il traffico di rete. Accedevo da remoto tramite un client SSH prelevando la cattura di rete e decrittando gli hash grazie alle mostruosamente grosse tabelle di rainbow sul computer fisso.
Max ha più volte insistito sul fatto che la DMZ è morta perché la LAN ormai è troppo facilmente attaccabile.
Io ho fatto proprio l'esempio di quanto sarebbe facile insinuare in una azienda un piccolo Access Point come quello da usare come ponte per un attacco.
Signori, IPSEC esiste da un pezzo e qui, ancora una volta, sono mancate le giuste precauzioni!
- Nella demo conclusiva alla nostra sessione, con il famigerato guanto da scheletro che ho recentemente rispolverato a Bologna, mi sono loggato a Windows XP con un'impronta digitale falsa che ho riprodotto facilmente con mezzi casalinghi.
Sono ormai tre (3) anni che ripetiamo che il fingerprint NON è un dispositivo di sicurezza e per questo motivo il driver Microsoft non funziona sui sistemi operativi Server.
Ancora una volta sono mancate le giuste precauzioni, oltre all'invasione della privacy per i 'normali' utenti bancari.
Un ultimo disclaimer per chi non è pratico di sicurezza. "Security through obscurity" NON funziona. Chi teme che, parlando di queste cose, si diano "cattive" idee ai malintenzionati si sbaglia di grosso. La storia della sicurezza dimostra esattamente il contrario. È necessario parlarne fino alla noia per rendere al corrente tutti del potenziale pericolo. Chi se ne capisce e ha cattive intenzioni non ha bisogno di ripetizioni.