Re: vb & mssql apps : security issue

From: Stephen J Whiteley (hackateerTHEYAAHHOOOatyahoo.com)
Date: 05/07/03 

Date: Wed, 7 May 2003 11:40:33 -0400

You could have the password an encryption of the username. As long as they
don't have a copy of the encryption algorithm you use (i.e. keep your source
code secure) you should be set. Then, you don't even need to know the
password, just the username....(have an application that can create a new
username/password combination for the database).
...just a thought.

"David Portas" <REMOVE_BEFORE_REPLYING_dportas@acm.org> wrote in message
news:etr3g$8EDHA.432@TK2MSFTNGP12.phx.gbl...
> Are you using SQL authentication? Create a SQL user or SQL application
role
> for each distinct level of access that is needed. Then, within your
> application, use the appropriate login for each user as they log in to the
> application.
>
> Add two columns to your Users table to store the SQL login name / app role
> and a key with which to decrypt the SQL password (the encrypted password
> itself would be stored in a Logins table). Encrypt the key with a secure
> hash of the user's own password. And encrypt the actual password with a
> secure hash of the key. That way, the password required for database
access
> is never visible to the user. The key provides a level of indirection so
> that you can change the SQL password regularly without affecting users'
own
> logins.
>
> It would still be technically possible for a legitimate user to
> reverse-engineer the encryption in your app and then, equipped with his
> valid password, determine the true SQL password but hopefully that's an
> acceptable level of risk for your application (if not, I think you should
to
> look at third party authentication products). For an outside intruder this
> system is as secure as your password encryption and protocols.
>
> --
> David Portas
> ------------
> Please reply only to the newsgroup
> --
>
> "^Crazy Coder^" <saba@clubrt.com> wrote in message
> news:OMIzWn8EDHA.432@TK2MSFTNGP12.phx.gbl...
> > Dear all,
> >
> > Today I got something to share the idea and asking that properly someone
> > around here got the better solution regarding on our apps security
issue:
> >
> > Here you go:
> > 1. I make my application using VB+MS_SQL, on my program i got my own
user
> > log_on uid/pw screen.
> >
> > 2. Since I don't want to deal by myself with any of password issue.
> > So, using MS_SQL password seem to be the best, then I created every user
> on
> > MS_SQL Server (on Security.Logins) which could be able to get access to
my
> > main DATABASE and permit them as 'public' only, nothing more.
> >
> > 3. My program pool-in uid/pw from the user entries screen to check
> whatever
> > he/she is valid on MS_SQL.Security.Logins. Only just that, and doing
> nothing
> > more.
> >
> > 4. Then on my APPS : I use other uid/pw on MS_SQL which have the higher
> user
> > level to deal with in any place (***)
> >
> > 5. On my program I stored their NAME and LEVEL on my USER_TABLE to
> restrict
> > them as desired. For sample I want to block them on some screen.
> >
> >
> > What's the GOOD point ?
> > 1. this is my main reason:
> > I don't want any of my created user to be able to use any other tools
like
> > Enterprise Manager or Query Analyzer to get direct access to my DB, even
> > 'only see' any data on my TABLEs. (because they got no have any right)
> >
> > 2. safe time:
> > Create and use only one account that be able to get access r/w to my
main
> > db.
> > Another user just create their uid/pw with (almost) blank permission.
> >
> > What's the BAD point ?
> > 1. Here's you all may have any suggestion:
> > If anyone could be able to CRACK, DE CODE my APPS.EXE they could see
> uid/pw
> > that I use on all my APPS. (see #4*** above)
> >
> > What's the better way to deal ?
> >
> >
> >
> > Regards,
> > ^CrazyCoder^
> >
> >
> >
> >
>
>

Relevant Pages

  • Re: Security, Password Protected Computer
    ... > How secure is an XP Home Edition machine that has one user ... > with forced login and password protection (meaning, ... of encryption such as the NTFS encryption built into XP, BUT, and a ...
    (microsoft.public.windowsxp.basics)
  • Re: how to decrypt an encrypted stored proc in 2005
    ... SQL 2005 still obfuscates object encryption in a similar manner to SQL 2000. ... tinyint,@procNameLength int ... SELECT @BasePos = 1 ...
    (microsoft.public.sqlserver.security)
  • Re: how to decrypt an encrypted stored proc in 2005
    ... remove the feature for the same reason. ... Using a stronger encryption algorithm ... So the feature is unchanged in SQL 2005 from SQL 2000. ... SELECT @BasePos = 1 ...
    (microsoft.public.sqlserver.security)
  • Re: Encryption of application configuration block
    ... If your trying to protect an Sql login password then instead create an Sql ... access to Sql Server objects based on the current users' Windows account. ... If your really must encrypt your connection strings here are some links, ... I come to secure the app.config file via encryption. ...
    (microsoft.public.dotnet.general)
  • Re:Hi THis is Code is to encrypt or decrypt you password Using Sql
    ... I have a very good solution for encryption and decryption using sql ... 1 and smith are uid and username. ... Do you use SQL Server 2005? ...
    (microsoft.public.sqlserver.programming)