Is Query Slower When There Are More Columns in one Table? I'm trying to build a login function and was wondering:

Does more columns in a table mean the longer (and slower) the query takes to return a result?

I'm asking because I'm debating on whether to


put only the essential columns to allow users to login (userID, username, password, email, etc.) and separate the other data (first name, last name, address, etc.) to another table with a FK constraint
just put everything in one table.


Would login processing time be affected if I choose option 2 (due to SQL query taking longer because of the many columns)?
I have a related blog post here: Do You Have Tables In Your Tables? that I'm going to quote a bit from.


  What Makes Them (wide tables) Bad? 
  
  They’re nearly impossible to index
  efficiently:
  
  
  Queries will hit them in many different ways 
  WHERE clauses will be
  unpredictable 
  SELECT lists will vary wildly 
  
  
  When indexes pile up to support all these different queries, locking and blocking will start to become larger issues.


Other things you may need to consider: 


LOB data (MAX columns, etc.)
Query Memory Grants
Modification concurrency


Putting everything in one table sounds like a bad idea. If users are allowed to change any information related to a profile that you've listed (name, telephone, personal information, etc.), those queries are now competing to locate and modify rows alongside your app tracking login information.

It's a recipe for bad blocking and deadlocks down the road. 

The "one big table" approach sounds quite convenient at first, but the convenience early on will never surpass the inconvenience you face later of needing to split the table up into a proper schema.