As barry already explained, these two hints can complement each other, but they are typically used in different contexts and to solve different resource contention issues.
The WITH (NOLOCK) tells the server to employ READ UNCOMMITTED transaction isolation level, which means you are exposed to the risk of reading uncommitted ("dirty") rows which may be subsequently rolled back and thus have never existed. It does prevent classic deadlocks on reads, but at the expense of getting invalid data.
If there is a chance GetUser or CheckPassword operations may access the profile of the user being updated through UpdateUser operation, then WITH (NOLOCK) is not recommended to use.
The WITH (ROWLOCK) table hint can be used with either SELECT, INSERT, UPDATE, and DELETE statements, to instruct the server to only apply a Range-Lock(s) on the rows being modified or added, and to avoid escalating the lock to page or table level. The rest of rows are not locked and can be accessed by another query.
However, if the default transaction isolation level at the SQL Server is READ COMMITTED or more restrictive, and SNAPSHOT READS are not enabled, then an active INSERT, UPDATE, or DELETE transaction may still block the SELECT query, if lookup conditions match or overlap.
use the hint when only a single or only a few rows will be affected by the query, to keep the lock from locking rows that will not be deleted by the query. That will let another query read unrelated rows at the same time instead of having to wait for the delete to complete.
If you use it on a query that will delete a lot of rows, it may degrade the performance as the database will try to avoid escalating the locks to a larger scope, even if it would have been more efficient.

WITH (NOLOCK) is used with SELECT statements when time sensitivity on retrieving data down to the microsecond is not eccential, or selecting a newly added record is down properly.
WITH (ROWLOCK) is used by UPDATE statements to keep the locking of the row at a row level lock and not to escalate it to more than one row or even a table lock.
You should always be using both in you select statements and update statements, as well as you need to properly create indexes, cache repitive data so as not to rapid fire query the database for data that changes little, and look at your login logic to determine if it is not performing unecessary logging of data, and also inspect your SQL error logs for errors that could be slowing access to your web site.