hmm, smells like "bad idea led to bad design" kinda ...
first: try to re-phrase what it does mean that a user have to log into your application
on most cases, it's either some CMS where the application is used to alter datasebase records and the user account is only for 1) logging who has what done and 2) controll what who can do
on the other hand - if you want to restrict access to you application by tryin to "guard" it behind some sort of challenge-response (aka login aka user has to provide proof of knowledge) it's the wrong approach
third guess: you're developing some sort of forum/board/game/what ever needs to identify a user - that way, your users authenticate against stored information used at registration - but not to gain access to your application but rather to the provied service - hence not logging into your application but rather into your service provided by your application
second: after you cleared what goal you want to approach - it's mostly not a question about how to achieve your set goal - but rather what pitfalls to avoid
rather drastic example: a simple "multi-user" game - worst approach: save username and password in clear - better: only save hashed values and create a challenge-response system where the user doesn't provide the data itslef but rather proof of knowledge - pitfall: choosing a to-weak hash-algo could open up the possibiity someone founds a hash-collision and therefore is able to log in with something not the real secret but somethings resulting in the same hash - there lot of services offering huge MD5 rainbow tables - you simple put in a hash in HEX and get something that would result in the given hash - or on really big servies you get multiple responses all matching the hash
third: if you got stuck try to phrase your issue and we can try to provide help