Sounds like you have a major problem if knowing someone else's customer id is a problem!

It's only dangerous to know someone's id when knowing someone's id is sufficient to impersonate the person. That's usually the case for session ids*, and is inexcusable anywhere else.

And if you think 5 digits would be sufficient in that case, you're quite mistaken! It would take but seconds to find a valid id! (50 attempts on average if you have 1000 customers.) Session ids are usually 8 times longer (128 bit rather than 16).

* — And even then, the risk is mitigated by binding the session id to the user's IP address and expiring the session id on short order.

I think you probably do want the AUTO_INCREMENT though. The thing about the "easy to guess" is that it only matters if your design or security is fundamentally flawed. Any number of ecommerce sites use numeric Ids for customers. What does knowing that 321299 is a customer Id buy you? Nothing unless the site in question is inherently hackable. You can also create your own sequences with most DBs too so that the "numbers" can look like anything you like.

The nice thing about GUIDs is that they can be shared between applications whereas DB Ids are purely local. I have considered using them so that user accounts or content (or even versioned code, CSS, etc) could be packaged as data-based plugins; nothing to install, just insert the SQL. I haven't got around to it ... but one of these days.