Results 1 to 9 of 9

Thread: user permission

  1. #1
    Join Date
    Apr 2008
    Posts
    2

    Unanswered: user permission

    I have developed Client Server application which use VB6.0 in front end and MSAccess in back end. i want to setup password for each user login in a table(say Pwd field in Employee table). but my concern is if any of the users open the access table and check for pwd field for the password. is there any way of setting up user permission not to open table Employee (in this case)?? I least prefer to for encrypting particular field!!

    i tried to set DB password, but it would open exclusively then other user's may not able to open the DB??

    How can i tackle this?

    Thanks in Advance,

  2. #2
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    sorry to say that it is complete nonsense to store plaintext passwords in a table.

    hashing is so simple:
    Code:
    Public Function izyHash(plainText As String) As String
    
        'caller is responsable for ensuring that plainText is a valid, non-empty string
        
        Dim obHash As New CAPICOM.HashedData
        
        On Error GoTo err_izyHash
        
        obHash.Algorithm = CAPICOM_HASH_ALGORITHM_SHA1
        obHash.Hash ByVal plainText
        izyHash = obHash.Value
        
    exit_izyHash:                                   'housekeeping
        plainText = ""                                  'clear the inbound
        Set obHash = Nothing                            'clear the object
        Exit Function
        
    err_izyHash:                                    'generic errors handling
            MsgBox Err.Number & ": " & Err.Description, vbInformation, "Error in izyHash"
            izyHash = ""
            Resume exit_izyHash
            
    End Function
    you save hashed password (preferrably salted-hash password: find something to salt with, even something primitive like your application name) and call
    izyhash("myApplicationName" & userPassword)
    ...save it in your table

    at login time, grab the user input, call
    izyhash("myApplicationName" & userInput)
    ...and compare with the saved value in the table.
    precisely zero civilians will crack it however long they stare at your table.


    izy
    currently using SS 2008R2

  3. #3
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Don't underestimate civilians.

    They can still copy the hashed value from one user's password (say their own) to another user's password (maybe an admin user) and they then can use their own password to access the admin user's account.

    Storing passwords in any accessible table is always a security risk imo.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  4. #4
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    fair point!
    fix is to include username in the hash.

    izy
    currently using SS 2008R2

  5. #5
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Then the civilian will still be able to:

    Login to the front end with their own credentials.
    Change their own username to the admin's username from the backend.
    Change their password with the front end.
    Copy their hashed password to the admin user's.

    ... And they're away again.

    You can make it harder and harder with each "fix" but remember that you usually won't know there's a problem to fix until it's too late.

    The only answer really is to store the hashed password values in an SQL Server / MySQL server table, which doesn't have a linked table to hack into. Then only db admins can hack the passwords.

    No system is totally secure though... there's always a way... the hacker just needs more tools / experience to do it.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  6. #6
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    NEVER EVER let your users touch your tables!
    George
    Home | Blog

  7. #7
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    Id suggest that the 'fix' is to use the netwrok logon ID, from API, not the dreaded Environ that wayr ound there is alwasy going to be somehting the malicious user wfind harder to fake.

    I seem to remeber there were some smarter encryption routines in CAPICOM, allthough bizzarely at one site the netwrok trolls decided that it was a brach of their security policy to allow the installtiaon of a security realted encryption DLL from Microsoft......

    some expleted deleted netwrok trolls.......

  8. #8
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Quote Originally Posted by georgev
    NEVER EVER let your users touch your tables!
    Agreed, but not always possible. JET backends can't be secured (unless I'm missing something terribly obvious ?) and unless you use SQL Server with no linked tables, people can get access.

    Quote Originally Posted by healdem
    Id suggest that the 'fix' is to use the netwrok logon ID, from API,
    Yeap, the network login is one of the best things to hash a user password with... unless you have a shared computer or users are freely exchanging windows passwords and still want security around only your application, then even that falls over.

    I refuse to believe there is a totally secure system
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  9. #9
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    In these days there are precious few environemnts that I work with that allow shared logon's, most (95%+ are single logon per user)

    its usually a disciplinary offence to leave your workstation logged on unattended, or knowingly allow others to use your workstation whilst you are logged on). normally the audit logfiel says who did waht and where based on the userid and computer id..... unless the user can prove someone has spoofed their user id its a disciplinary......

    Ive even come accross a site where you get one (possibly 2 if the first was very very minor) warning.... mess about with your computer privileges and you loose them.. if you loose your computer privileges then you are unable to do your work.. instant dismissal, without any rederess hars.. but it does concentrate the users minds (an oxymoron if ever there was) somewhat.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •