Seite 1 von 1
pwds absichern
Verfasst: Dienstag 10. Juli 2007, 18:31
von Costi
hmmm,
weil das einer der kritischten teile ist, frag ich mal lieber nach:
(code ungetestet)
Code: Alles auswählen
class People(SQLObject, BaseRights):
...
#we dont store pwds in plain text
pwd = StringCol(maxlength=40)
def _set_pwd(self, pwd):
return hashlib.sha1(pwd + "mysalt").hexdigest()
def _get_pwd(self):
raise AcessDenied, "no direct access allowed, use `guess_pwd` instead"
def guess_pwd(self, guess):
if self._set_pwd(guess) == self.pwd:
return True
else:
sleep(1) #make brute force offensives harder (@leonidas: ja, das ist ein inline kommentar;-)
return False
ist das ok so?
danke
edit:
verdammt, wie heist den `maxlength` in SQLobject
Verfasst: Dienstag 10. Juli 2007, 19:30
von BlackJack
Was soll dass den darstellen? Und wogegen willst Du die Passwörter absichern?
Verfasst: Dienstag 10. Juli 2007, 20:25
von veers
Meinst du nicht return s.digest()?
Kurz geschrieben wäre es dann:
Für das speichern in die Datenbank ist es eventuell klüger hexdigest() zu verwenden.
guess_password halte ich für einen schlechten Namen. Wie wäre es mit check_password, compare_password o.ä.?
Verfasst: Dienstag 10. Juli 2007, 20:49
von Costi
Meinst du nicht return s.digest()?
thx, ich meine `hexdigest`, damit man das in ein StringCol speichern kann
Was soll dass den darstellen? Und wogegen willst Du die Passwörter absichern?
das soll eine tabelle fuer benutzer einer web app darstellen
absichern will ich sie gegen nicht authorizierten zugriff (?)
Verfasst: Dienstag 10. Juli 2007, 20:59
von veers
Costi hat geschrieben:das soll eine tabelle fuer benutzer einer web app darstellen
absichern will ich sie gegen nicht authorizierten zugriff (?)
Also das macht dein Beispiel bestimmt nicht O_o
Verfasst: Dienstag 10. Juli 2007, 21:21
von Costi
Also das macht dein Beispiel bestimmt nicht O_o
spezifizieren......
Verfasst: Dienstag 10. Juli 2007, 21:39
von veers
Costi hat geschrieben:Also das macht dein Beispiel bestimmt nicht O_o
spezifizieren......
Du Hasht die Passwörter, wie soll das die Tabelle vor Zugriffen schützen?
Verfasst: Dienstag 10. Juli 2007, 21:53
von Costi
das hashen schuetzt nicht direkt vor zugriffe, muss es aber nicht weil nhemand mit dem hash nichts anfangen kann.
auserdem wird das direkte auslesen des hashes mittels SQLobject nicht ermoeglich
oder?
Verfasst: Dienstag 10. Juli 2007, 22:06
von BlackJack
Gegen was für Zugriffe willst Du den Hash schützen?
Und was meinst Du was in Zeile 13 passiert, wenn bei `self.pwd` die Methode `self._get_pwd()` aufgerufen wird und grundsätzlich eine Ausnahme auslöst.
Verfasst: Dienstag 10. Juli 2007, 22:59
von nkoehring
BlackJack hat geschrieben:Gegen was für Zugriffe willst Du den Hash schützen?
Ich glaube, es geht ihm einfach um die (Arbeits-)speichertechnische Sicherheit des Programmes zur Laufzeit.
BlackJack hat geschrieben:Und was meinst Du was in Zeile 13 passiert, wenn bei `self.pwd` die Methode `self._get_pwd()` aufgerufen wird und grundsätzlich eine Ausnahme auslöst.
Das sieht eher nach einer "Information" fuer Entwickler aus, als nach einem anderweitig tiefgruendigen Konstrukt.
Verfasst: Dienstag 10. Juli 2007, 23:05
von BlackJack
Was ist "(Arbeits-)speichertechnische Sicherheit des Programmes zur Laufzeit"? Gegen welche Angriffe soll das schützen?
Und was meinst Du mit "einfach nur Information für Entwickler"? Ich meine ja, Quelltext der nicht funktioniert ist auch eine Art Information, aber was soll das dem Entwickler sagen!?
Verfasst: Dienstag 10. Juli 2007, 23:54
von nkoehring
Ich wollte ja eigentlich ins Bett, aber ich war dann doch noch n bissl am programmieren ^^
BlackJack hat geschrieben:Was ist "(Arbeits-)speichertechnische Sicherheit des Programmes zur Laufzeit"? Gegen welche Angriffe soll das schützen?
Ich kann auch nur Vermutungen anstellen, aber es geht wohl darum, das Passwort auch zu schuetzen, wenn ein ominoeser Angreifer die Moeglichkeit haette, den Speicher (bzw Teile davon) auszulesen.
Es hat also mehr was damit zu tun, den Passwort-Teil sauber zu programmieren, als "websicher".
BlackJack hat geschrieben:Und was meinst Du mit "einfach nur Information für Entwickler"? Ich meine ja, Quelltext der nicht funktioniert ist auch eine Art Information, aber was soll das dem Entwickler sagen!?
Es soll dem Entwickler wohl sagen: Ja, nicht selbst das Passwort pruefen, sondern die vorgefertigte Funktion dazu nutzen. Aber so fuer wirklich sinnvoll halte ich die Idee auch nicht ^^
Ja frag halt Costi... ich geh jetzt ins Bett, nachdem ich nochwas gepostet hab ^^
Verfasst: Mittwoch 11. Juli 2007, 00:08
von Y0Gi
Solange der Client das Passwort im Klartext schickt, wird das immer irgendwo im Speicher des Servers vorbeikommen, egal wo man es speichert.
Wenn der Passwort-Hash nicht entdeckt werden soll (denn dann könnte man in über Rainbow Tables entziffern), muss man die Tabelle (via DBMS) und die Daten (durch entsprechende Programmierung der Webanwendung) sowie den gesamten Server entprechend absichern, damit da keiner drankommt.
Verfasst: Mittwoch 11. Juli 2007, 01:03
von Costi
wergessen wir das ganze:
ich werd doch nicht SQLobject benutzen, bin ja von django darauf umgestiegen, weil django sql`s wrapper ding fehlermelduungen einfach verschluckt das scheint aber bei SQLobject auch der fall zu sein
und wenn die template das auch sowieso schon tut wird das ganze zu schwer zum endbugen.
*frustiert*