Newsgroup: it.comp.sicurezza.varie
Titolo: Website authentication security.

Mi servirebbe un secondo parere (anche un terzo o un quarto se e'
possibile).
C'e' un website il cui accesso e' consentito se le seguenti condizioni si
verificano:
1. l'IP address del client e' nel loro database
2. La web request e' nel formato che loro si aspettano.
Quando ho chiesto ulteriori informazioni circa la sicurezza del loro
servizio, ho ottenuto la seguente risposta:
"Our Services will only accept requests from a registered IP address that
we have in our system and it will only accept request in the required
format. Once it receives these requests then it will return the data to
the registered address. While it may be possible to spoof the address
that the request came from it is my understanding that it is not
possible to take over the address completely. This means that the data
would always be returned to the registered address.
If someone spoofed the address all that would happen is that the request
would appear to have come from the registered server the resulting data,
assuming they we able to duplicate the request format correctly would be
sent back to the registered server.
1.Quello che mi chiedo e': vi fidereste di questo metodo di authenticazione?
(io non ne ho mai visti prima, in commercial environment).
2.Quali sono le possibili metodologie di attacco (IP spoofing included)
3. vi sembra una risposta esauriente?
Ta
Tony

 prendo il suo posto, ip compreso).
Inoltre, dipende da come e' implementato quel controllo, ho visto cose
che voi webmaster... tipo controllo dell'IP dagli header passati dal
proxy.
-- 
HappyCactus - Linux User #209744
* 
http://sourceforge.net/projects/qixl
* 
www.google.com
 / 
groups.google.com

 3. vi sembra una risposta esauriente?
No, a mio parere. Prevederebbe, come minimo, d'informare che buona
parte della sicurezza di questo metodo richiede precauzioni che un
utente deve prendere al livello della rete del client: prevenzione
o rilevamento d'attacchi mim, uso di protocolli di routing sicuri,
enforcing della assegnazione univoca degli ip, ecc. Tutto, come e'
ovvio, con l'intento di limitare le possibilita' d'attacco, non di
renderlo "impossibile".
Fabio

 la vedo come un'ipotesi molto praticabile, francamente.
Quindi pensi che il sistema adottato da quella azienda e' comunque
relativamente sicuro in quanto fare il blind spoofing e' una ipotesi poco
praticabile?
Grazie
Tony

 renderlo "impossibile".
Ovviamente...
Grazie per la risposta!!
Saluti
Tony

 environment). 
No, perchè non è un metodo di "autenticazione". Sarà un'altra cosa. 
Filtrare gli ip può essere utile & interessante, ma chiamarla 
autenticazione è una bestemmia visto che l'indirizzo ip non dice 
assolutamente nulla di chi/cosa sia il remoto (in fondo basta che un 
computer dichiari di essere quell'indirizzo e automaticamente lo è... è 
sufficiente essere raggiungibili). 

 HTH
Grazie, lo e' stato!

 lo stack in questione.
Consiglio questo storico paper:
http://razor.bindview.com/publish/papers/tcpseq/print.html
E il naturale seguito:
http://lcamtuf.coredump.cx/newtcp/


 1.Quello che mi chiedo e': vi fidereste di questo metodo di authenticazione?
In realtà io non vedo alcuna autenticazione...
Hola..
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Skull says:
The old signature is gone...
Won't you suggest me a new one?!?

 In realtà io non vedo alcuna autenticazione...
Perche no', in un certo qual modo lo e'...IP + webform. La definizione di
authentication non dice che deve necessariamente essere a user name &
password, oppure un certificato...

 e siamo alla 3.4
Vero, infatti c'e' l'update dell'anno successivo.
Comunque rimane un ottimo paper per capire come funziona il meccanismo.


 e' un'altra storia. :)
Ma può essere anche molto banale, per quello che ne sa il server che 
"autentica"... :-)

 
http://lcamtuf.coredump.cx/newtcp/
Grazie!!
Tony

 password, oppure un certificato...
Non mi trovi d'accordo.
Una autenticazione la fai su qualcosa che il client ha o su qualcosa che
il client sa, non su qualcosa che il client è, e la storia di rsh e
famiglia dovrebbe essere ormai chiara a tutti, si spera.
A questo punto rimane solamente la modalità di richiesta dei dati, che
però non si sa quanto sia complessa:
se la "modalità" di cui si discute consiste nel prendere la richiesta
"normale", crittarla usando una chiave ben precisa e passarla come
parametro a un cgi, si può parlare di autenticazione, basata sullo shared
secret (ovvero la chiave).
Se è semplicemente il fatto di richiedere "quella URL lì, nascosta sotto a
12 directory", il tutto sta poco in piedi: basta assistere ad una sessione
(sniffando, passandoti dietro mentre la fai o altro) e si possono già
avere dati da cui partire...
Nella fattispecie, poi, mi pare di intuire che non ci sia una correlazione
tra l'ip del client e il modo in cui la richiesta deve essere effettuata
(ip diversi *devono* fare richieste in modo diverso?), per cui non si
prospetta una combinazione univoca come nel caso classico username +
password... E' come se fai una autenticazione in cui tutti gli username
hanno la stessa password... non va molto lontano, come concetto...
Forse ho capito male?


 tcp/ip stack era proprio bucato in questo senso...
Be', anche altri, molto piu' blasonati, non scherzano. Se non ricordo 
male (sui link di happycactus dovresti trovare tutto) sistemi operativi 
come AS/400, AIX e IRIX fanno veramente pena.
Fabio

 Ti stai riferendo allo static mac address assignment?
Si puo' fare in modo che il routing venga ammesso solo per le coppie
ip-mac ammesse e bloccare le porte degli switch in modo che soltanto
un ben definito mac address possa esservi collegato. In questo modo,
prescindendo da una valutazione della corretta implementazione delle
due misure di protezione, diventa poco probabile lo spoofing ip (non
impossibile...). E' una pratica, ovviamente, che potrebbe richiedere
investimenti sia in termini di hardware (es. switch adeguati) sia di
gestione (gestire creazione e aggiornamento tabelle dei mac address,
gestire regole fw, ecc.). Il trade off dei costi non puo' che essere
valutato caso per caso.
Fabio

 operativi come AS/400, AIX e IRIX fanno veramente pena.
Leggere le performance di OS/400 mi ha fatto non poco scompisciare. Un
attack rate del 100% non e' male (prng profondamente bacato). In questo
caso, molto meglio il server microsoft.


 caso, molto meglio il server microsoft.
Queste affermazioni mi lasciano un po' perplesso. Ho sempre avuto
l'impressione che IBM AS/400 (che costano tralaltro una barca di soldi)
fossero famosi per la loro sicurezza. A parte errate configurazione da parte
dell'admin nel settare le autorizzazioni degli users, non ho mai avuto
grossi problemi di sicurezza con tali 'bestie'.
Correggetemi se sbaglio, ma non ho visto molte security alerts su questo
sistema. Sara' per il fatto che non e' un sistema molto comune? O il
'security through obscurity' funziona in questo caso?
Ho notato che almeno qui in NZ, IBM sta cercando di spostare il mercato
sulla vendita dei pSeries (AIX) e sta tralasciando quella degli
iSeries(OS/400).
Comunque qualsiasi informazione circa vulnerabilita' note dei sistemi AS/400
e' molto ben accetta...
PS ma il tcp/ip stack dei nuovi sistemi AS/400 e' stato patchato a dovere o
lo stack continua a fare pena anche oggi?
Ta
Tony


<cut>
Grazie Fabio per la tua esauriente risposta...
Tony

 Forse ho capito male?
Mi sa che hai capito bene, sono quelli che offrono il servizio che hanno non
capito un tubo...
Tony

 L'ip address puo' essere considerato qualcosa che il client ha...
Non direi, perchè il portare quel "qualcosa" su un'altra macchina non
richiede il doverlo prelevare dalla macchina iniziale.
Per "qualcosa che il client ha" di solito si intendono i certificati,
per fare un esempio: il client lo ha e non puoi portarlo su un altra
macchina senza prelevarlo dalla prima (e quindi averla sfondata in
qualche maniera).
Per l'ip -palesemente- non è così...
Hola...
-- 
Emanuele Balla  aka Skull -  Public Key #661E5CBF on 
www.keyserver.com
+----------------------------------------------------------------------+
"And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports
on it, you know they are just evil lies." (By Linus Torvalds)

 male [...]
ricordi male, era molto peggio. Parliamo di Cisco con ISN ad incremento 
fisso ad intervalli fissi. Però il grafico di dispersione veniva bello, 
quasi artistico
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.4. C, C++ and ASM developers
                               and beta testers are welcome!

 dovere o lo stack continua a fare pena anche oggi?
boh, bella domanda.
