Re: How to insert a parenthesis into a field

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Giac (anonymous_at_microsoft.com)
Date: 10/08/04 

Date: Thu, 7 Oct 2004 20:03:59 -0400

Thanks David,
Ah... you're dead right and as it is now, I'm storing both. I figure that
scrambling the password is adequate to keep people from knowing that they
are passwords stored in a database provided I don't name the field something
conspicuous like 'password'. I'm not doing rocket science here, just
creating a record to read. Each scrambled password is also hashed. If the
scrambled password is altered, the hash won't work. I have enough checks
and balances to satisfy management and that satisfies me. I hash dates,
cpuids, networklogins, userid's, aliases... anything I can think of that
someone might play with. Probably slows the database down a bit, but since
it all gets done at startup, I can live with that too. I probably overdo
the hash thing and one of these days, I'll trim it down. For now, too much
is probably enough. Something like that.
Thanks for the advice though. Never thought of using the varbinary to
store the string. I do use it for the hash. The special characters should
store in the varchar though, shoudn't they?
Giac

"David Portas" <REMOVE_BEFORE_REPLYING_dportas@acm.org> wrote in message
news:0tqdndBnn_mcJPjcRVn-jg@giganews.com...
> Your code actually worked for me. The parenthesis shouldn't cause a
> problem but some non-printable, control characters might. I suggest you
> insert data like this as VARBINARY rather than strings so that you can
> safely insert any byte values you may require.
>
> Passwords? Don't store them in the database. Store a secure hash of the
> password in the database instead. Maybe you meant that this was a password
> hash but your use of the word "scrambled" implied to me that this is an
> *encrypted* password. Storing encrypted passwords is not really a good
> idea from a security point-of-view.
>
> --
> David Portas
> SQL Server MVP
> --
>
>

Relevant Pages

  • Re: Best practice for password hashing
    ... unless there is a database compromise. ... The most common scheme is never to store passwords, but to instead store a cryptographic hash of the password. ... That way, if the base machine is compromised, they can't guess very rapidly unless they can compromise both machines. ...
    (sci.crypt)
  • Re: Perl function for password encryption and decryption
    ... store them to a database. ... password and compare it to the database. ... hash what they entered and compare it to the stored hash. ...
    (perl.beginners)
  • Re: LAMP - Program Design with Perl
    ... Does that mean that the second column of the database stores all ... > into a hash and then go through all possible parameters ... strings with the info needed to access the data base. ... could store the info needed to display the data. ...
    (comp.lang.perl.misc)
  • Re: Perl function for password encryption and decryption
    ... store them to a database. ... password and compare it to the database. ... hash what they entered and compare it to the stored hash. ...
    (perl.beginners)
  • Re: Newbie - Is this Reasonable?
    ... because this hash is stored in the database. ... So you use PKCS5v2 to generate a key hash from a salt and the user's passphrase, then store the salt and the hash in a database. ... are even more critical in database applications because the payoff from tampering with selected fields may be much higher, fields tend to be fixed-length so it's easier to tamper with them in a meaningful way, and databases lend themselves to off-line analysis, so the attacker can marshall more resources and take more time to attack your system. ... You're using a stream cipher for encryption. ...
    (sci.crypt)