[ASP/MS Access] gecodeerd wachtwoord wil niet opslaan *

[SilentSimon]

Ik heb een website waar de wachtwoorden van gebruikers via RC4 wordt opgeslagen in de Access database. Dit werkt allemaal prachtig op een paar users na.

Nu kijk ik wat er aan de hand is, en het blijkt dat Access zit te kloten met een paar ge encrypte wachtwoorden. voorbeeldje:

Er staat in het veld: Q2
klik ik op dat veld staat er ineens: Q2&%(()*
Dat onderste is uiteraard goed, maar ik vraag me af waarom Access daar Q2 van maakt? Als ik dan mn cursor weer van dat veld afhaal staat er ineens weer Q2.

vreemd vind ik dat
(bovenstaand wachtwoord is fictief bedacht )

[Boss]

Ik denk dat Access 1 van de karakters aanziet voor een carriagereturn / linefeed of iets dergelijks en het daarom niet goed kan weergeven in de tabel.
Misschien als je het veld groter maakt (in hor/vert richting) kan je er misschien meer van zien?

Verder werkt het toch wel, of geeft dit effect ook problemen?

[SilentSimon]

De gebruikers die dit probleem hebben krijgen dus de volgende foutmelding:

Microsoft JET Database Engine error '80040e14'

Syntax error in string in query expression 'nickname='blaat' and wachtwoord='Q2'.

----
terwijl iedereen die dit probleem niet heeft gewoon normaal kan inloggen e.d.
Verder als ik op een veld klik met het probleem dan zitten daar characters in, die ook in andere ge'encrypte wachtwoorden voorkomen in de database. Dus access lijkt me daar geen moeite mee hebben

[ Voor 31% gewijzigd door SilentSimon op 26-04-2004 17:29 ]

[gorgi_19]

Echo eens je volledige SQL Statement?

[SilentSimon]

strsql = "SELECT count(1) AS aantal FROM users WHERE nickname='" & login & "' and wachtwoord='" & pass & "'"

[gorgi_19]

De geparsede versie eigenlijk...

Oftewel: Response.Write strsql

Ik ben vooral benieuwd naar gekke tekentjes, ' enzo...

[ Voor 64% gewijzigd door gorgi_19 op 26-04-2004 17:46 ]

[SilentSimon]

SELECT count(1) AS aantal FROM users WHERE nickname='a' and wachtwoord='Q2

[gorgi_19]

SilentSimon schreef op 26 april 2004 @ 17:55:
SELECT count(1) AS aantal FROM users WHERE nickname='a' and wachtwoord='Q2

Ik gok dat dit icm ASP is?

[SilentSimon]

correct nu mist hier ook zon " ' " single quote, terwijl dit met andere wachtwoorden wel goed is, er zit geen quote in het gecodeerde wachtwoord.

[gorgi_19]

Wat staat er nu in de variabele pass; iets van \r\n oid?

[SilentSimon]

niks vreemd, iig geen tekens die ook niet in andere gecodeerde wachtwoorden staan

[bigbeng]

Access heeft toch een aantal gereserveerde tekens die je op een speciale manier moet behandelen.
o.a:
% * _
Zou het probleem hier iets mee te maken kunnen hebben?

[SilentSimon]

Het linkerplaatje is zoals het er staat als ik er met mn cursor op sta.
Het rechtplaatje zoals het normaal staat zonder dat ik er met mn cursor op sta.
Terwijl daar natuurlijk hetzelfde als het linkerplaatje zou moeten staan

[gorgi_19]

* gorgi_19 gokt, nu ik al die grappige tekentjes zo zie, op een encoding probleem.. Waarom niet SHA1 of MD5 als hasing algoritme?

[SilentSimon]

zou kunnen ja, maaarrr liever niet natuurlijk
verder vind ik het supervreemd dat de wachtwoorden die daar "fout" zijn wel ge'emaild kunnen worden naar hun eigenaar, en dat werkt perfect.
Maar daar heb ik de wachtwoorden ook niet een een SQL statement, wat ik bij het inloggen wel gebruik.

[SilentSimon]

ach, al opgelost.
SQL had er blijkbaar moeite mee, dus heb het met een omweggetje opgelost thnx anyway

[gorgi_19]

SilentSimon schreef op 29 april 2004 @ 00:06:
ach, al opgelost.
SQL had er blijkbaar moeite mee, dus heb het met een omweggetje opgelost thnx anyway

Kan je hier nog posten hoe je het uiteindelijk hebt opgelost? Mochten mensen in de toekomst hetzelfde probleem hebben, dan vinden ze in dit topic ook de oplossing.

[Twilight Burn]

Die vreemde tekens zijn binaire karakters. Een hash zet een string om naar een andere (binaire!) reeks. Bij het hashen kan er dus een ascii-10 of 13 (CR of LF) "verschijnen". Ik denk dat het daarom fout gaat. Als iedere byte van de gehashte reeks "hexadecimaal" maakt, of op een andere manier omzet naar een subset van de hele ascii reeks die geen problemen heeft, dat je dan het probleem niet meer hebt.

[SilentSimon]

ik zoek al tijdje btw voor een ander project een goede hexadecimaal MD5 hasher (kan niet vinden )

Ik wil het straks bij een volgende project natuurlijk niet weer op deze manier doen.
Ik heb het opgelost als volgt: iets minder netjes en veilig denk ik maar dat geeft in dit geval niet zoveel.
Het RC4 component wat ik gebruikt heb is niet een one-way geval maar een encrypter/decrypter in samenwerking met een key. Redelijk veilig dus.
ik vraag nu met behulp van SQL de nickname op en de daarbij behorende encrypte key. Die Decryp ik vervolgens en vergelijk ik met het ingevoerde wachtwoord.

ipv dat ik dus het ingevoerde wachtwoord Encrypt en dan met SQL de AND statement gebruik doe ik het in principe nu andersom.

Het volgende project is voor de nieuwsschierigen versie 2 van deze website waarvoor ik dit gebruik

[Twilight Burn]

Ik weet niet wat je huidige hasher/rc4 encrypter voor datatype teruggeeft, maar als het een array van "byte" is, dan kun je elk karakter omzetten naar de hex waarde hiervan en die concatteneren, als het een string met allemaal karakters is, kun je karakter-voor-karakter de ascii waarden nemen, die naar hex omzetten en al dat concatteneren.