need help designing a database for PC booking system ? I have 3 labs and students should be able to book a PC 1 week or even 1 Day before if they want to work extra. Database should store student Login time and info. (Well this is some programming technique) but I need to have some fields so that data should be dumped into database so as to keep a record if the student has consumed his/her time or not.
Very Urgent a quick response will be highly appreciated.From that informaiton, I would reccomend three tables, (Labs, Students, and schedule) Possible design:
Labs
Labname
Location
...
Students
StudentPK
Firstname
Lastname
...
Schedule
ScheduleID
Labname
StudentPK
Date
Logintime
Logouttime
...
Probably more you could do but this should get you started, researching normalizaiton should help as well.
HTHsql
Showing posts with label students. Show all posts
Showing posts with label students. Show all posts
Friday, March 23, 2012
Monday, March 12, 2012
password storage
Hi everybody
I am working on a school project where I am writing a software for course registration. I have different users Students, Faculty, and Administrator. They are allowed to log in using their ID and password. I was wondering how could i store password and userID securly. Should I store it in the individual table or separately?
Any suggestion is appreciated. Also, if somebody has worked on this kind of project, please let me know.
Thanks a lot[I am using SQL 2000.|||You need to use what is known as "one-way" encryption. The good news is that this is simpler than "two-way" encryption where it is must be possible to both encypt and decrypt a text string. In one-way encryption you apply a function to encrypt the string, and then store the encrypted result in your table. When someone submits their password to log in, you apply the same encryption function to their password and then compare it to the encrypted version stored with their personal record. If the two match, you let the dude in.
There are some built-in encryption functions within SQL Server which are simple to use. I think they are called dbencrypt and dbcompare, or something similiar. The disadvantage with these is that they are undocumented functions, and if you upgrade your database to a new version of sql server Microsoft does not guarantee that it will use the same encryption algorythm in future versions. The result (and this has happened in past upgrades...) is that the passwords your users submit no longer match the versions stored in your database. They must all be reset and new ones must be entered.
You can write your own one-way encryption algorythm, or I have one that you can use that is more secure than the one supplied with SQL Server. (The built-in function has been cracked and the solution is available on the internet.)
blindman
I am working on a school project where I am writing a software for course registration. I have different users Students, Faculty, and Administrator. They are allowed to log in using their ID and password. I was wondering how could i store password and userID securly. Should I store it in the individual table or separately?
Any suggestion is appreciated. Also, if somebody has worked on this kind of project, please let me know.
Thanks a lot[I am using SQL 2000.|||You need to use what is known as "one-way" encryption. The good news is that this is simpler than "two-way" encryption where it is must be possible to both encypt and decrypt a text string. In one-way encryption you apply a function to encrypt the string, and then store the encrypted result in your table. When someone submits their password to log in, you apply the same encryption function to their password and then compare it to the encrypted version stored with their personal record. If the two match, you let the dude in.
There are some built-in encryption functions within SQL Server which are simple to use. I think they are called dbencrypt and dbcompare, or something similiar. The disadvantage with these is that they are undocumented functions, and if you upgrade your database to a new version of sql server Microsoft does not guarantee that it will use the same encryption algorythm in future versions. The result (and this has happened in past upgrades...) is that the passwords your users submit no longer match the versions stored in your database. They must all be reset and new ones must be entered.
You can write your own one-way encryption algorythm, or I have one that you can use that is more secure than the one supplied with SQL Server. (The built-in function has been cracked and the solution is available on the internet.)
blindman
Subscribe to:
Posts (Atom)