Office: (Office 2010) Passworttabelle schützen

Hallo,

ich möchte eine Accessanwendung erstellen, in der man über verschiedene Schaltflächen im Fomular andere Formulare aufruft.
Aber zuvor soll ein Anmeldeformular erscheinen, mit Benutzerauthentifizierung.
Die Benutzer sollen unterschiedliche Rechte haben, so dass bestimmte Benutzer bestimmte Schaltflächen nicht drücken können.
Benutzer und die dazugehörigen Passwörter wollte ich in eine Tabelle abspeichern.
Wie kann ich jetzt diese Tabelle schützen.
Ich will mit Frontend und Backend arbeiten, die Passworttabelle soll in das Backend.
Benutzen tue ich Access 2010.

:)

 

Servus taotao2,
der folgende Download-Link sollte Dir helfen.
http://www.arbtersound.de/sonderseit...HASH_FE_BE.rar
Das Backend ist passwortgeschützt und muss beim ersten Start aus der readme.txt eingegeben werden.
Der Rest ist selbsterklärend.
Ich empfehle, diese in jede Access-DB einbindbare Beispiel DB erst am Ende der Entwicklung einer DB
einzubauen.
Zum Ausprobieren funktioniert sie natürlich auch autonom.

 

Danke erstmal ich schaue es mir an.

 

Hallo
in meiner Doc s. Fusszeile unten rechts
Seite 189
hab ich was zum Thema
lies das evtl. ist das was für Dich
hier findes Du die dazu passende muster MDB
https://dl.dropboxusercontent.com/u/...WPMusterDB.zip

zum Testen benuze User 123 mit pw 123 (benuzer)
oder user 1321 mit pw 321 (admin rechte)

 

Hallo
habe ein Fehler gemacht
folgende User sind Richtig / möglich:

zum Testen benuze User 123 mit pw 123 (benuzer)
oder user 321 mit pw 321 (admin rechte)

z.Z gibt es 4 Benutzrt Gruppen
kann jedoch in der Tabelle TblBenutzerGruppen erweitert werden !
ID BenutzerGruppe
1 Administrator
2 Benutzer
3 Benutzer0
4 Benutzer1
5 ?????????????

 

Hallo,
alles was irgendwo im Klartext steht unterliegt gewissen Unsicherheiten.
Eine sichere Speicherung in einer Tabelle wäre, wenn du dir eine reversible Verschlüsselung ausdenkst, und z.B. per VB6 oder .Net eine kleine DLL mit dem Decodierer und Codierer erstellst.
Diese DLL sollte natürlich nicht als Ergebnis die Passwörter im Klartext zurückliefern (dann wäre die Arbeit ja umsonst) sondern die Validierung der Passwörter gegenüber eingegebenen Daten machen und nur das Ergebnis ja/nein zurückgeben.
Aber auch hier liegen weitere Fallstricke die es zu umschiffen geht, z.B ...Where Passwortprüfung(Eingabe) = True Or 1 = 1 - wobei als Beispiel Passwortprüfung() die implementierte Funktion in der DLL wäre. In Verbindung mit ... Or 1 = 1 wird nämlich jedes Kriterium Wahr.

Gruß Andreas

 

Servus avogt_at_home,
siehe in meiner angeführten Beispiel DB.

 

Hi Andreas, für eine Authentifizierung reicht doch z.B. ein nicht-reversibler Hash-Wert.

 

Hallo,
oder so *Smilie

Andreas

 

Unabhängig vom Anhang von Ohrkester - den ich mir noch nicht angeschaut habe - ist es imo immer noch unsicher wenn im VBA-Code der Codierer steht - auch ein Hash-Wert in einer Tabelle ist ein Text-String den man mit bekanntem codiertem Passwort einfach ersetzen kann.

Andreas

Hey Ohrkester, super Beispiel.*top

 

Wenn man Quellcode offen weitergibt, ja. Ich ging schon davon aus, dass der
Codierungsteil in einer mde/accde landet.

 

\@Marsu65: wo ist das Problem?
selbst bei diesem offenen Code von Nouba wird niemand so einfach ein
Passwort aus den Tabelleneinträgen auslesen können.

 

Hi,
das brauchst du auch gar nicht.
Setze ein Breakpunkt, und gib dein WunschUserName ein, schau was dieser als Hash-Wert zurückliefert, ändere die Tabelle den Usernamen ab,
gib ein Wunsch-Passwort ein, schau was als Hash zurückkommt, ändere die Tabelle nochmals und fertig ist das überschriebene Passwort, mit dem du dich jederzeit einloggen kannst.

Hab das eben mal gemacht, waren keine 2 Minuten bis es klappte.

Einziger Schutz bietet eine MDE/AccDE bzw. Auslagerung von Funktionalität in eine DLL, was generell keine so schlechte Idee ist.

Andreas

 

Ohne mir die Datei angesehen zu haben (Kann rar-Dateien hier nicht öffnen):
Wenn der Passwortvergleich (If Berechneter Hash-Wert = gespeicherter Hash-Wert)
in einem offenen Code steht, ersetze den Vergleich durch 1=1 (s.o.) ... *wink.gif*

 

Hallo,
ich habe dazu auch noch eine Meinung *wink.gif*
1)
In einer "administrierten" Windowsumgebung sollte jedes zusätzlich Passwort vermieden werden. Zumindest der Programmierer kann das Passwort auslesen und das ist immer ein Sicherheitsrisiko, wenn z.B. der Nutzer sein Windowspasswort verwendet.
Es gibt den Windowsnutzernamen und er sollte zur Authentifizierung reichen.

2)
Darüber hinaus geht es um den Schutz der Daten selbst und da hilft das Passwort gegen "Auskenner" recht wenig.