Kommentarerne, der påpeger, at SMTP ikke kræver godkendelse, er korrekte. Når det er sagt, alle tre af de muligheder, du har angivet, er usikre, forudsat at serveren bruger råvarehardware og -software. Jeg vil vise, hvorfor hver enkelt er usikker, selvom jeg ikke følger din oprindelige ordre.
Hvad hvis nogen skulle stjæle serveren? Så kunne de bare åbne filen eller databasen, læse adgangskoden og straks få adgang til alle de vigtige oplysninger i virksomheden. Så medmindre du har bevæbnede vagter omkring serveren dag og nat, er dette allerede ret usikkert.
Men det bliver værre. Intet computersystem er fuldstændigt usårligt over for angreb, og flere velkendte angreb (Sonys PlayStation Network, for eksempel) i de seneste par år har vist, at en angriber kan komme til indholdet af diskfiler og databaser uden fysisk adgang. Ydermere ser det ud til ud fra dit spørgsmål, at den pågældende server er beregnet til at acceptere pakker (HTTP-anmodninger, indgående e-mails osv.) fra omverdenen, hvilket booster din angrebsoverflade.
Dette er fristende, men det er endnu mere skadeligt end mulighed 2 eller mulighed 3. For det første er et privat endeligt strengfelt gemt i .class-filen, der er genereret af Java-compileren, så med denne mulighed gemmer du allerede den ukrypterede adgangskode på serverens harddisk. Efter at have kompromitteret serveren som i mulighed 2 eller 3, kan en angriber bare køre javap for at få klartekst-adgangskoden ud af .class-filen.
Denne tilgang udvider dog din angrebsflade endnu mere. Hvis adgangskoden er gemt som en del af kildekoden, er den pludselig tilgængelig for alle udviklere, der arbejder på koden. Under princippet om mindste privilegium bør udviklerne ikke kende ekstra adgangskoder, og der er en meget god grund her. Hvis nogen af udviklerne maskiner er stjålet eller kompromitteret udefra, kan angriberen se gennem den kompromitterede maskines harddisk og få klartekst-adgangskoden. Så er der kildekontrol. En af de virkelig vigtige fordele ved kildekontrol er, at den giver dig mulighed for at inspicere enhver tidligere version af din kode. Så selvom du skifter til en sikker metode i fremtiden, hvis adgangskoden nogensinde er gået ind i kildekontrol, er kildekontrolserveren et potentielt angrebspunkt.
Alle disse faktorer viser, at selvom HTTP/mail-serverens sikkerhed er i top, så øger mulighed 1 angrebsfladen så meget, at HTTP/mail-serverens sikkerhed ikke rigtig hjælper.
Ekstra detaljer:I begyndelsen specificerede jeg "forudsat at serveren bruger råvarehardware og -software." Hvis du ikke bruger råvarehardware og -software, kan du gøre ting som at starte fra skrivebeskyttet lager og kun bruge en krypteret database, hvilket kræver, at en person angiver dekrypteringsnøglen ved hver opstart. Derefter lever den dekrypterede information kun i hukommelsen og bliver aldrig skrevet til disken. På denne måde, hvis serveren bliver stjålet, er en angriber nødt til at afbryde serveren og mister dermed al den dekrypterede information, der kun var i hukommelsen. Denne form for opsætning bruges nogle gange til en Kerberos KDC (med serveren i en låst boks for ekstra sikkerhed), men bruges sjældent ellers, og er ærlig talt overkill, når der er en nem måde at løse dit problem på uden at gå til alt dette ekstra udgift.