[JAVA] Veilig JDBC-wachtwoord *

[WieMie]

Ik wil via een Java-applet een MySQL-DB aanspreken. Nu is dit op zich geen probleem. Zelfs heel makkelijk.

Nare is, het wachtwoord voor de DB staat in de .class file (plain text, ook na compilen). Dit is niet de bedoeling. Gezien het niet mijn database is (althans, ik heb login gehad) heb ik een account voor alle handelingen (drop table, insert, select, alles...), het is dus niet de bedoeling dat de gebruikers van de applet dit wachtwoord hebben.

Is er een mogelijkheid dit te beveiligen? (dat het uiteindelijk plain-text over de lijn gaat is jammer, maar niks aan te doen) Het gaat mij erom dat niet iedereen zomaar het wachtwoord kan lezen.

[4VAlien]

Het enigste veilige is volgens mij het password eruit slopen en elke keer intypen

[voodooless]

De vraag is ook: waar gebruik je het. Hebben de gebruikers toegang tot de class files?

[WieMie]

4VAlien schreef op 19 juni 2003 @ 09:57:
Het enigste veilige is volgens mij het password eruit slopen en elke keer intypen

Maar, dan moet ik gebruikers wachtwoord geven, dat is nou net niet de bedoeling... Is er niet iets van een codering mogelijk? (zoals in PHP) Zat er al aan te denken zelf iets te coden (wachtwoord splitsen, enkele codes op toepassen). Als het maar niet meer plan-text is teurg te vinden.

Gebruikers hebben toegang tot de .class files... anders kunnen ze applet niet uitvoeren.

[ Voor 10% gewijzigd door WieMie op 19-06-2003 10:02 ]

[Janoz]

NOOIT een applet gebruiken om rechtstreeks te verbinden met je DB. Dat is vragen om problemen. De code (dus ook degene die de beperkingen op de gebruiker legt) wordt op de client gedraaid en het is een illusie om te denken dat dat beschermt of onaanpasbaar is.

Je hebt in principe twee opties:
1 - Alle gebruikers van het applet krijgen een acount op de DB. Deze gegevens moeten de gebruikers opgeven en het applet gebruikt deze om in te loggen. De beperkingen worden nu door de DB geregeld.
2 - Een tussenserver gebruiken. Hierdoor heeft de client maar een bepaald aantal acties die hij de server uit kan latn voeren. De server maakt verbinding met de DB en laat de sql er op los. Op dit moment worden de verschillende beperkingen bepaald door de zelf geprogrameerde server.

[Alarmnummer]

Je zou er misschien een obfuscator overheen kunnen gooien. Ik weet niet of die stringconstanten ook veranderen. En verder heeft java ook wel een ecryption/decryption library.

[Janoz]

WieMie schreef op 19 juni 2003 @ 10:00:
[...]


Maar, dan moet ik gebruikers wachtwoord geven, dat is nou net niet de bedoeling... Is er niet iets van een codering mogelijk? (zoals in PHP) Zat er al aan te denken zelf iets te coden (wachtwoord splitsen, enkele codes op toepassen). Als het maar niet meer plan-text is teurg te vinden.

Gebruikers hebben toegang tot de .class files... anders kunnen ze applet niet uitvoeren.

Je kunt er nog zulke rare dingen op los laten, waneer ik je class file heb kan ik daar binnen 1 minuut het wachtwoord uit halen. Gebruikers hebben immers alle informatie beschikbaar om het weer te decoderen anders zou het op de client draaiende applet het ook niet kunnen doen. Daarnaast wil je niet dat een DB open staat voor de buitenwereld samen met het feit dat er een login met delete en drop rechten redelijk makkelijk voor handen is.....

Dat iets bij php wel kan komt omdat dit bij de server draait en niet bij de client.

[voodooless]

Je zou redelijk simpel iets met XML kunnen maken, zodat het applet via HTTP XML info stuurt naar de server, en deze zet dat dan weer om naar SQL. Zo ook met het ontvangen...

[Hmmbob]

of met php in plaats van xml.

beetje knutselen, maar in ieder geval die applet zelf geen verbinding met de DB laten maken...

[curry684]

* curry684 heeft maar even de titel gefixed omdat ie niet wist wat een velig wachtwoord was...

[Verwijderd]

Een (goede) obfuscator zorgt er wel voor dat Strings niet meer leesbaar zijn na decompilen...maar toch is het idee om met passwords in de applet zelf te werken niet handig.

[voodooless]

Een obfuscator haalt alleen de classe en variabale namen door elkaar, string constantes, als wachtwoorden e.d. blijven echter behouden.

[Verwijderd]

Een ac gebruiken die enkel dingen in de db mag bekijken helpt ook al flink natuurlijk.
En met JDBC is het zeer zeker mogelijk om de pw en alle andere date niet plain over de lijn te sturen kijk hiervoor naar de SSL functie van JDBC in de docs.

[WieMie]

Verwijderd schreef op 19 June 2003 @ 19:33:
Een ac gebruiken die enkel dingen in de db mag bekijken helpt ook al flink natuurlijk.
En met JDBC is het zeer zeker mogelijk om de pw en alle andere date niet plain over de lijn te sturen kijk hiervoor naar de SSL functie van JDBC in de docs.

Maar, dan moet je server dat ook ondersteunen, dat doet ;ie niet... Is server van school... Ook moeten studenten (de gebruikers) dingen naar de DB kunnen schrijven (althans, zaken die ze invoeren moeten worden ingevoerd.) Heb wel om een extra account gevraagd, maar krijg ik nu niet...

[Verwijderd]

deepspace schreef op 19 June 2003 @ 18:31:
Een obfuscator haalt alleen de classe en variabale namen door elkaar, string constantes, als wachtwoorden e.d. blijven echter behouden.

Dan heb jij geen goed obfuscator...een voorbeeldje:

Java:

public class Test
{
    private String password = "secret_word";
    
    public static void main(String[] args)
    {
        new Test();
    }
    
    public Test()
    {
        System.out.println(password);
    }
}

En na obfuscaten en decompilen:

Java:

public class Test
{

    public static void main(String args[])
    {
        new Test();
    }

    public Test()
    {
        a = zkmToString("\023\032'>B\024 3#U\004");
        System.out.println(a);
    }

    private static String zkmToString(String s)
    {
        char ac[];
        int i;
        int j;
        ac = s.toCharArray();
        i = ac.length;
        j = 0;
        if(i > 1) goto _L2; else goto _L1
_L1:
        ac;
        j;
_L10:
        JVM INSTR dup2 ;
        JVM INSTR caload ;
        j % 5;
        JVM INSTR tableswitch 0 3: default 72
    //                   0 52
    //                   1 57
    //                   2 62
    //                   3 67;
           goto _L3 _L4 _L5 _L6 _L7
_L4:
        0x60;
          goto _L8
_L5:
        127;
          goto _L8
_L6:
        68;
          goto _L8
_L7:
        76;
          goto _L8
_L3:
        39;
_L8:
        JVM INSTR ixor ;
        (char);
        JVM INSTR castore ;
        j++;
        if(i != 0) goto _L2; else goto _L9
_L9:
        ac;
        i;
          goto _L10
_L2:
        if(j >= i)
            return new String(ac);
        if(true) goto _L1; else goto _L11
_L11:
    }

    private String a;
    public static boolean b;
}

Hoezo Strings zijn nog te lezen na decompilen?