RSA-software knipt inlogdata op en verdeelt deze over servers

Onder de noemer distributed credential protection heeft RSA technologie aangekondigd voor het veilig opslaan van wachtwoorden. Een wachtwoord wordt daarbij in twee stukken gehakt en op verschillende servers opgeslagen.

Volgens RSA wordt een wachtwoord bij zijn distributed credential protection niet alleen versleuteld, een veel gebruikte methode voor het veilig opslaan van inloggegevens in databases, maar ook opgedeeld in twee stukken. Vervolgens worden de twee stukjes data randomized opgeslagen op verschillende servers die, mits zo geconfigureerd, op twee fysiek gescheiden locaties draaien. RSA stelt dat met het verknippen en opdelen van inloggegevens de kans aanzienlijk kleiner wordt dat een hacker inloggegevens weet buit te maken zodra hij toegang heeft verkregen tot een database.

Mochten hackers toch een systeem weten binnen te dringen, dan biedt RSA aan systeembeheerders de optie om alle opgeslagen inloggegevens opnieuw op te splitsen en te versleutelen. Hierdoor zou een hacker gedwongen zijn om op twee servers tegelijk in te breken en inlogdata buit te maken nog voordat hij wordt gedetecteerd.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

RSA, dat vorig jaar zelf nog met een geraffineerde hack te maken kreeg, wil zijn dcp-beveiligingssoftware nog dit jaar op de markt brengen. Goedkoop is dcp echter niet; een licentie zou 150.000 dollar kosten. Volgens het beveiligingsbedrijf zijn deze kosten echter aanzienlijk lager dan de potentiële schadeclaims die een bedrijf na een succesvolle inbraak boven het hoofd hangen.

Tegenover de BBC stelt een beveiligingsonderzoeker dat de beveiligingsmethode van RSA weliswaar een nieuwe drempel opwerpt voor hackers die servers aanvallen, maar dat het niets doet aan phishing. In de praktijk is phishing, waarbij aanvallers via bijvoorbeeld e-mails 'hengelen' naar inloggegevens bij eindgebruikers, de succesvolste methode voor het buitmaken van wachtwoorden. Circa 80 procent van alle gestolen wachtwoorden zou via phishing zijn verkregen.

Reacties (51)

[Bilel]

Redelijk groot bedrag voor redeljik grote onzin TBH. Waarom? Rechten. Je moet misschien op 2 verschillende servers raadplegen. Maar op beide servers zal (waarschijnlijk) precies dezelfde OS draaien en de authentificatieclient zal PRECIES dezelfde rechten hebben. Het is dus even makkelijk om in te breken op 1 server als op 2, makkelijker zelfs omdat je na server 1 gewoon weet wat je moet doen om de 2e te kraken.

Overigens ook niets nieuws, elke programmeur kan met kleine moeite wachtwoorden automatisch laten splitten en plaatsen op 2 databases.

[Sibylle]

Juist...misschien moet je solliciteren bij RSA (of als je dat niks vindt bij Oracle, Apple, Google etc.). Met dit inzicht zal je hun een hoop werk en veel kosten besparen

De problemen die jij beschrijft zijn de problemen waar RSA voor stond tijdens het ontwerpen van dit systeem en die zijn gewoon opgelost want anders is het systeem niet compleet en waardeloos.

Ik zal niet ingaan op alles in je bericht, maar het feit dat de servers op twee verschillende locaties staan en achter verschillende firewalls en beveiliging zegt al één ding: je moet wellicht beide servers op een heel andere manier hacken.
Je kunt Server2 bijvoorbeeld zo instellen dat die alleen bereikt mag worden door Server1 en Server1 moet bereikbaar zijn voor sowieso Server2 en (via een aparte server?) de client. Alleen dit al levert een cruciaal verschil in hacken van de twee.

[martijnve]

Je hebt gelijk dat er bij RSA knappe koppen werken die er verstand van hebben maar zelfs met die instelling kan ik me niet aan de indruk onttrekken dat dit wel erg veel weg heeft van security by obscurity en dat het inderdaad in de meeste implementaties (let op ik zeg niet dat dit de schuld is van het ontwerp) na het hacken van de eerste server kinderlijk eenvoudig zal zijn om op de 2 exact hetzelfde truukje toe te passen.

Daarnaast als ik op beide servers een verschillende random one-time-pad per wachtwoord opsla plus het password wat met beide is ge XOR'd heb je dezelfde situatie: een hacker die een server hackt weet niets en je kunt na het stelen van de data makkelijk het password XOR'en met twee nieuwe pads en de hacker moet weer opnieuw beginnen.

Dat iets ontwikkeld is door een bedrijf met expertise hoeft niet te betekenen dat het een goede oplossing is. Bedrijven ontwikkelen producten om geld te verdienen, en als de klant er mee geholpen is is dat mooi meegenomen. Maar met name in de beveiligings-wereld is een klant tevreden tot ze er achter komen dat je systeem lek is, wat waarschijnlijk nooit gebeurt.

[Reactie gewijzigd door martijnve op 27 juli 2024 21:16]

[Glashelder]

Volgens jouw redenatie heeft een SALT ook nooit zin, want als je eenmaal toegang hebt tot een server kan je ook de source inzien, en nagaan wat voor SALT er is toegepast.

Een SALT helpt dan ook alleen tegen een databasedump, niet tegen een volledige server hack. Hier geld hetzelfde lijkt mij. Als een hacker een dump heeft van een van de databases, kunnen ze daar, zonder database 2, onmogelijk mee achterhalen wat de wachtwoorden zijn.

[ieperlingetje]

Een salt heeft absoluut niks met geheimhouding te maken. Meestal wordt de salt gewoon als extra veld bij de hash van het wachtwoord van de gebruiker bewaard.

[djiwie]

Precies, een salt maakt het genereren van rainbow tables veel bewerkelijker omdat ieder wachtwoord een andere salt heeft. Ook met een niet-geheime salt blijft het bewerkelijk om voor iedere gebruiker het wachtwoord te kraken.

[MMaI]

Er is vaak per applicatie vaak maar één salt, niet een salt per gebruiker, en wat een salt doet is simpelweg eht wachtwoord langer maken zodat een rainbow table of brute force te lang duurt om effectief te zijn.

[Janoz]

@MMal

Onzin. een salt is absoluut niet om een wachtwoord langer te maken. Een salt is bedoeld om er voor te zorgen dat je niet 1 rainbowtable kunt maken voor alle gebruikers. Door voor elke gebruiker een andere salt te gebruiken krijgt elke gebruiker zijn unieke hash berekening waardoor elke gebruiker apart bruteforced moet worden.

Voor de hele applicatie dezelfde salt gebruiken maakt de salt compleet nutteloos.

[Reactie gewijzigd door Janoz op 27 juli 2024 21:16]

[Vaan Banaan]

Ter aanvulling op Janoz:
Dat zou een doodzonde zijn, want dan zie je van 2 gebruikers met hetzelfde wachtwoord ook dezelfde hash terugkomen.
Dus iedereen een andere salt en die mag inderdaad best naast de hash bewaard worden.
Wat jij bedoelt, is misschien 1 extra geheime globale salt die er nog een keer extra overheen gegooid wordt (waar ook de kreet pepper voor misbruikt wordt)

[TheGhostInc]

Ik ben het niet met je eens. Alsof een bedrijf gegarandeerd een goed product moet leveren. En dat knappe koppen altijd een goed resultaat opleveren.

Dit lijkt mij echt een marketing product. Leuk voor de PR en marketingjongens, maar functioneel is dit gewoon onzin. Een goed beveiligde server heeft dit niet nodig, want dan loop je met bijvoorbeeld een keylogger al zoveel meer risico dat dit risico veel kleiner is. Een slecht beveiligde server zal sowieso hiermee niet gaan werken, of heeft bijvoorbeeld op de server een plaintext wachtwoord en stuurt dit daarna naar deze machines.

Als je kijkt naar de recente hacks dan is het meestal een uitgefaseerd systeem dat wordt gekraakt of een marketing pagina oid. Het is zelden dat er een productiesysteem zo lek is, en als dat wel het geval was, dan was er al helemaal geen geld voor dit systeem.

[mhkool]

Als je inbreekt op server1 en server2 is alleen via server1 bereikbaar, is het redelijk simpel om allebei de helften van de wachtwoorden te krijgen.

Het idee van wachtwoord-hashes opdelen is leuk, maar het zet niet echt veel zoden aan de dijk: als je eenmaal binnen bent, kun je APIs en dergelijke gebruiken om langzaam de database met wachtwoord-hashes volledig te kopieren.
Of als je ingebroken hebt, ga je naar de magamentconsoles van de storage apparatuur en kopieer je de databases via de achterdeur van het diskarray. Kortom, als je eenmaal binnen bent zijn er vele manieren om data te kopieren, ook als de data op twee locaties staat.

[Schnoop]

Mochten hackers toch een systeem weten binnen te dringen, dan biedt RSA aan systeembeheerders de optie om alle opgeslagen inloggegevens opnieuw op te splitsen en te versleutelen.

Als RSA die optie biedt (zonder dat de gebruiker zijn wachtwoord opnieuw op moet geven) dan kan in theorie de hacker dit toch ook, of mis ik nu iets?

[the_shadow]

RSA weet op welke twee servers de twee delen staan, een hacker weet dat in het geval van 3 of meer servers niet.

[mhkool]

Onzin. Alles wat software "weet" kan achterhaald worden.

[Sibylle]

De systeembeheerder heeft natuurlijk wel toegang tot meer middelen. Denk aan een onbereikbaar copy met alle orginele hashes bijvoorbeeld.
In principe kan de hacker misschien wel herverdelen, maar daar heb je denk ik weinig aan (wat zou je ermee willen bereiken?).

[Thralas]

Het idee erachter is dat 'hersplitsen' enkel nut heeft indien slechts een enkel systeem compromised is. Als beide systemen compromised zijn, dan heeft de aanvaller al een hash van het password in handen (en faalt het protocol).

Zie ook [url=https://www.rsa.com/rsalabs/node.asp?id=2592]deze[/url[ paper van RSA voor (waarschijnlijk relevante) details.

[TrailBlazer]

De vraag is of de database server gehacked wordt of de front-end server die toegang heeft tot de database server(s) met wachtwoorden. De front-end server is gevoelig voor SQl injectie de database server voert alleen maar uit wat de front-end hem vraagt.

[sfranken]

Als het goed is beveilig je je front-end gewoon tegen SQL injectie, dat is zo basaal dat het gewoon zielig is als je dit niet standaard doet!

In zo'n beetje elke (web)programmeertaal kan dit zo makkelijk dat "het is nodeloos complex" ook geen excuus meer is.
In PHP bijvoorbeeld zitten er standaard functies in om dit te doen, *_real_escape_string() is een van de simpelste om maar een voorbeeld te noemen.
(gebruik die functie niet alleen! Gebruik er ook nog strip_tags() oid bij..)

[Niosus]

real escape string gebruiken is juist de verkeerde manier... ja, het zal er ergens wel in voorkomen maar als je het overal manueel moet gaan toevoegen ga je heel rap in de problemen zitten met grote applicaties.

Het is beter om al je SQL queries via een eigen functie te laten gaan die alles controleert voor het te verzenden. Op deze manier moet je maar op 1 plek zoeken naar kwetsbaarheden en ben je veilig in het geval dat je er NIET aan denkt. Je moet er dus niet bij nadenken om het veilig te maken zolang je de "bewezen" functie gebruikt, terwijl in het andere geval je telkens opnieuw eraan moet denken. Nu kan je beweren wat je wilt, maar in een project waar duizenden manuren insteken gaan fouten zitten en gaan mensen soms dingen vergeten.

Escapen en tags strippen en eventueel nog html chars om XSS tegen te gaan is slechts een deel van de beveiliging. 0 day exploits op serversoftware kunnen ook voorkomen. Of wat dacht je van bedrijfsspionage, inbraken of onverantwoordelijke admins? Er zijn gewoon belachelijk veel manieren om informatie vast te krijgen. In plaats van elke manier apart aan te pakken pakt RSA het hier gewoon wiskundig aan: Het is gewoon ONMOGELIJK wiskundig gezien om de data te reconstrueren met slechts 1 deel van de dataset. Of je nu te maken hebt met een hack of en inbraak of wat dan ook maakt niet meer uit. 1 enkele hack levert niets meer op. Dit geeft je als bedrijf tijd om de andere server te randomizen en beter te beveiligen voor er definitief schade is. Nu moeten ze 2 hacks doen binnen een bepaald interval EN dan nog eens uitpluizen hoe ze het moeten decoden. Het is absoluut niet onmogelijk om gegevens te stelen, maar wel een pak moeilijker... Dit bovenop de huidige beveiligingssytemen zal alles buiten de allergrootste hacks effectief tegenhouden of belachelijk duur en moeilijk maken.

(als we RSA mogen geloven toch)

[thof]

Parameterized queries en geen gebruik meer maken van mysql_* maar van de MySQLi klasse scheelt al een hoop. Striptags gebruiken heeft geen zin, want dan krijg je geëscapete data in je database wat niet zo netjes is aangezien het escapen wat mij betreft bij de uitvoer dient te gebeuren. Zo moet het voor een webpagina wel door bijvoorbeeld html_special_chars heen maar voor een reguliere applicatie niet. Mooie van ASP.NET MVC Razor is dat deze manier van output de default is waardoor XSS niet mogelijk is, tenzij je het expliciet toestaat.

[mhkool]

Samenvattend: met de twee wachtwoord-hash databases op 2 servers wordt wachtwoorden stelen een klein beetje moeilijker.
Aangezien in datacenters steeds meer nieuwe technologieen gebruikt worden, maakt juist die nieuwe technologieen het mogelijk om makkelijk van de ene server de data van de andere server te kopieren.

Ik heb in een ander commentaar aangegeven dat je dit via de managementconsole van de storage arrays kan doen. Je kunt het ook via de hoogbeschikbare cloud doen want die cloud is natuurlijk verdeeld over 2 datacenters net als die 2 RSA servers. Als een hacker eenmaal binnen is, heeft hij een grote keus uit technologiene die hij kan misbruiken om zijn doel te halen.

[dvz89]

Dat is slechts een deel van de oplossing. Natuurlijk moet user submitted data worden gefilterd, maar het echte probleem zit hem in het aan elkaar plakken van je queries. Dat zou een taak voor je database driver of ORM moeten zijn met bijvoorbeeld parameterized queries. De PHP communitie lijkt zich vooral nog te richten op alleen het filteren van input met esoterisch genaamde functies. Niet bedoelt als flame, maar het wordt tijd dat we het probleem niet alleen maar zien als een filter probleem.

[djiwie]

PHP biedt ook parameterized queries aan, bijvoorbeeld via PDO.

[drernie]

Dus RAID stripe maar dan voor wachtwoorden, dan maar hopen dat er geen server crashed. En als een server niet bereikbaar is om wat voor reden heb je een probleem.

[Sibylle]

Nee, totaal anders dan RAID stripe...
Hier heb de dezelfde informatie verdeeld over verschillende fysieke locaties met elk hun eigen firewalls en beveiliging. DAT is de kracht hierachter.
edit: verduidelijking; dezelfde informatie als dat je normaal op één server hebt. De verdeling is zo dat een van elk wachtwoord de helft op server1 en de andere helft op server2 staat.

Als je wilt kun je de servers op elke locatie gewoon redundant draaien en elke minuut backups maken. De kans dat het fout gaat is dus ongeveer even nihil als de kans dat het fout gaat bij een systeem met één locatie.
editL verduidelijking; redundant opstellen als in dat je van elke server een redundant copy hebt.

Overigens heb je nu ook een probleem als je server niet bereikbaar is...dus daar verandert er niks. Downtime is nu afhankelijk van twee locaties en dus iets kwetsbaarder, maar daarvoor krijg je een hoop beveiliging terug.

Als je een random schema van her-randomizing en verdeling hebt, is deze opzet vrijwel niet te hacken. Je moet dan als hacker zijnde al tegelijk de twee locaties hacken, de wachtwoorden op een juiste manier aan elkaar plakken. Of je moet de locaties meerdere malen weten te hacken zonder gedetecteerd te worden (zoals ook in het artikel wordt aangehaald).

[Reactie gewijzigd door Sibylle op 27 juli 2024 21:16]

[drernie]

In het artikel staat: Vervolgens worden de twee stukjes data randomized opgeslagen op verschillende servers die, mits zo geconfigureerd, op twee fysiek gescheiden locaties draaien.

Daaruit concludeer ik dat de data wordt opgesplitst en op verschillende locaties wordt bewaard. Dus niet identieke data.

[Eagle Creek]

De fysieke scheiding lijkt hier inderdaad plaats te vinden om de vertrouwlijkheid te waarborgen en niet de beschikbaarheid.

M.a.w: als de fysieke locatie gecompromitteerd is heeft men nu slechts toegang tot een half wachtwoord, en niet het hele wachtwoord. Tegelijkertijd is het wachtwoord geheel verloren wanneer één locatie verloren gaat (bijvoorbeeld door brand of in braak).

Dat is dus wat anders de redundantie die hierboven genoemd wordt .

[Thralas]

Een attacker komt niets te weten over het wachtwoord bij een enkele compromise (dus ook geen 'half wachtwoord'). Zie ook deze paper.

[wica]

Sorry hoor. Maar het weten van een half wachtwoord is lijkt mij voldoende.
Je weet de lengte van het wachtwoord en aan de eerste helf zou je al kunnen opmaken wat de 2de helft is.

Naast dit, er is altijd 1 plek, waar het volledige wachtwoord bekent is. De webserver, waar de gebruiker zijn wachtwoord op invoerd.

[Alexxxxxxxxxx]

5E46C630A7DF8B6DB0100FEA51DE7C5C
DED23E315CEDDBFAB71BB1FDE531578B

Vind nu maar de rest van de hash uit

[Tukkertje-RaH]

Inderdaad...

Simplistisch gezegd worden de eerste 4 karakters op de ene server bewaard, en de laatste 4 karakters (bij een 8 karakter wachtwoord) op de andere server.

Een prima aanpak - mits er rekening wordt gehouden met 'sloppy admins', die op beide systemen dezelfde wachtwoorden gebruiken, en mits het mogelijk wordt om de twee servers op verschillende OS-en te draaien om je gevoeligheid voor zero-day exploits te verminderen.

Overigens, blijft de server die beide delen van de data samenvoegt dan niet toegang houden tot de gehele wachtwoordstring? Als je root access tot die ene server krijgt, ben je dan niet alsnog 'koning'?

[Jasper Janssen]

Dat is natuurlijk volslagen onzin -- je slaat NOOOOOOOIT maar dan ook nooit het wachtwoord op. Zelfs niet distributed.

Wat je opslaat is een (salted) hash. Er gaat dus op de ene server de ene helft van de hash staan en op de andere server de andere helft.

Ongeacht wat je precies opslaat: Er is geen server die beide delen samenvoegt. Er is alleen een server die de data nogmaals deelt en beide delen vervolgens naar de twee servers stuurt en van iedere server een ja of nee terugkrijgt.

[init6]

Welke vertrouwelijkheid?

Waar iedereen aan voorbij gaat is dat als een hacker in staat is om 1 server te kraken, hij dat bij een tweede ook kan doen.

Daar veel bedrijven patches als geheel uitrolt (vaak vanuit dezelfde patchmanager) en hetzelfde OS voor systemen gebruikt waar bepaalde software op staat heb je in feite 2 systemen draaien met dezelfde software, OS en security rules. De hacker zal dus een soort van mirror setup moeten aanvallen... Met de huidige middelen lijkt mij dat toch niet zo moeilijk? De hack die voor systeem 1 werkte herhaal je op systeem twee en doe je eventueel gelijktijdig, de hardware om eventuele berekeningen te laten doen kost een hacker niets welke een botnet tot zijn beschikking heeft. Zeker met Zeroday exploits heeft dergelijke setup geen schijn van kans.

Ik zie amper meerwaarde in dit product, zeker met het huidige prijskaartje. Ik denk dat 99% van de gehackte bedrijven beter af zouden zijn met het geld uitgeven aan een security audit om eens hun policies tegen het licht te houden. Er word naar mijn idee te veel geklungeld door systeembeheerders welke hun houdbaarheidsdatum al 10 jaar verstreken is.

[Fireshade]

Tegelijkertijd is het wachtwoord geheel verloren wanneer één locatie verloren gaat (bijvoorbeeld door brand of in braak).

Een beetje server (gezien de doelgroep die 150k moet ophoesten voor een licentie) heeft vast wel een off-site backup
Denk aan bedrijven als eBay en Amazon, die meerdere datacenters hebben. Een brandje of inbraak zal hen niets tot weinig doen.

[.Johnny]

Het gaat allemaal om marginale aantallen, maar principieel heeft drernie wel een punt en klopt het niet dat "De kans dat het fout gaat is dus ongeveer even nihil als de kans dat het fout gaat bij een systeem met één locatie."
Om precies te zijn is de kans dat het fout gaat met 2 locaties, 2x zo groot. Er zijn immers 2 locaties waar alles apocalyptisch mis kan gaan.
Nu kun je, zoals je stelt, wel allerlei backup mogelijkheden inbouwen, dat kan met 1 locatie natuurlijk ook. Dus zolang die paramters gelijk zijn is de kans dat er iets mis gaat, met het toevoegen van locaties waar je afhankelijk van bent, steeds groter.

[Verwijderd]

Er blijft volgens mij een zwakke plek, namelijk de server die de wachtwoorden stitched.....Nou hoeft deze volgens mij geen directe verbinding met internet te hebben maar het blijft de zwakke plek om aan te vallen. Als deze zelfde server ook nog eens verantwoordelijk wordt voor het decrypten van de gegevens wordt het wel heel interessant...

Zou dit trouwens een vlucht zijn om RSA langer in de markt te houden?

[Verwijderd]

Oftewel een salt op een aparte locatie opslaan. Dan is de prijs van anderhalve ton wel erg veel. Als je een random salt gebruikt en sterke encryptie dan heb je in feite al een splitsing van je wachtwoord (zet het salt op een andere machine) en een wachtwoorddump is dan ook niet te eenvoudig te kraken met brueforce. Ik ben benieuwd of bedrijven in de mooie RSA praatjes trappen, veiligheid wordt nog wel eens verkocht op basis van gevoel.

[Thralas]

Heb je deze paper al gelezen? Bij jouw 'triviale' manier van splitsen verkrijgt een attacker informatie over (een deel van) het wachtwoord bij een enkele compromise, bij het systeem van RSA niet.

[Verwijderd]

Volledig mee eens. 150.000 euro hoef je er niet voor te betalen, voor 1500 is hij in mijn ogen net zo veilig. Mits op de bovenstaande manier gedaan.

[Batiatus]

Voor multinational bedrijven die een groot vermogen hebben lijkt me dit een koopje vergeleken met de schade die ze kunnen ontvangen. De techniek klikt wel goed, maar voor kleinere bedrijven lijkt me dit niet rendabel. Leuk voor de technische bescherming van de wachtwoorden, maar je zult de domheid van je gebruikers er niet mee veranderen. phising en social engeneering zullen hier dan ook niet mee opgelost worden. Dat moet dan maar worden gedaan met security awerness trainingen.

[MMaster23]

Dit systeem zou alleen goed werken als beiden servers verschillend beveiligd zijn. Mocht er een exploit in zitten, dat zit deze op twee plekken.

Een hack heeft dat iets meer coordinatie nodig maar kan prima 2 doelen tegelijken kraken. Meeste hacks zijn pas minimaal een uur na inbraak te zien en tegen die tijd heeft hij beide delen al.

Leuk idee, uitvoering zal onmogelijk zijn (onmogelijk in de zin dat je een opstelling moet maken dat meerwaarde heeft over een single-source product).

[woudan]

De mogelijkheden om hierbij je eerste systeem op je eigen locatie te zetten die beveiligd is en het tweede systeem bij een 3e partij welke hiervoor oplossingen bied.

Bij deze 3e partij is beveiliging hun primaire doel en als ze dan mogelijk gehackt worden of het eerste systeem gehackt is zal het niet snel zijn dat de beveiliging op deze locaties hetzelfde is. En op deze manier is ook niet zo dat je data/passwords zomaar in te zien is door deze 3e partij.

[cbravo2]

Voor degenen die willen weten hoe zoiets kan werken: Galois Fields (en een uitwerking daarvan Reed Solomon)

Het gaat in het kort over hoe je informatie kan opdelen icm error correction (zeg maar parity).

Het is dus mogelijk om met een algoritme om te zeggen dat je minimaal X en maximaal Y servers nodig hebt om 't wachtwoord terug te krijgen. Y-X is het aantal parity bits.

[Verwijderd]

Wordt het niet tijd dat de e-mail protocollen POP/IMAP en SMTP eens worden herzien?
Het is toch gek dat als je weet dat 80% van de wachtwoorden via e-mail phishing worden achterhaald er technisch gezien nog steeds geen grote "updates" zijn geweest t.a.v. deze protocollen.

[xzaz]

Dus de hacker gaat achter het wachtwoord aan van de RSA-Software, of is deze ook weer beveiligd door middel van RSA? En deze.. nou ja je ziet het punt dat ik wil maken.

[jbdeiman]

Dat elk systeem zo veilig is als zijn/ haar zwakste schakel? Dat klopt, dat is met alles zo natuurlijk.
Op zich een mooi systeem, maar of het alle moeite waard is weet ik ook niet. Mits je server goed is beveiligd en je zelf de encryptie niet al te eenvoudig hebt, waardoor je na het "bruteforcen" van een SHA(1,2,3 of wat dan ook) hash nog steeds niet een bruikbaar password hebt, dan ben je ook al heel ver. Pak wat data uit een andere tabel gelinkt aan de "user" tabel ofzo en je kan als hacker ook maar moeilijk een wachtwoord meer achterhalen.

Is naar mijn idee echt iets voor grote bedrijven met zeer kritische informatie, maar zelfs daarvoor geldt dat het systeem dan wel heel veilig kan zijn maar dat daar dan niet dat systeem maar iets anders de zwakke schakel is. Uiteindelijk zal de netto winst maar nihil zijn, zonder dat er allerlei regeltjes (en controle op die regeltjes) omtrent wachtwoordbeleid en security worden gemaakt (en nageleefd).