1

If an error occurs, our web shop generates an error-code that is shown to the user. At the moment, it does not contain a time stamp but only the day of the month. That is non-intuitive but I assume the original intention was to give potential attacker as few information as possible.

However, it would be more convenient to include a more precise time stamp, e.g., YYYY-MM-DD-HH-MM.

Is it a security hole to show more precise time information?

I'm not talking about a high-resolution time stamp, but only the rough time so it is easier to locate logfiles and quickly find out which release of the code caused the problem.

All the attacker sees is the current time and the time zone that we use. Does not seem critical to me, but maybe I miss something.

Philipp Claßen
  • 1,024
  • 1
  • 8
  • 15
  • You could return a short "request ID" instead. If you really have a user who wants to be nice and contact support about the error, thay can report that XID. (You could even add a "sent mail" link which includes it. Having said that, the Date: header with second resolution should be fine. – eckes Feb 04 '15 at 22:04

3 Answers3

2

I don't see an issue here because the user will know the exact time they did something. Considering that a server needs to sync their time with an authoritative time source, there will be nothing "leaked" to the user that the user won't already know.

If you wish to hide some aspect of your server (like what time zone it resides) you can process your logs as UTC time as a generalized time format.

schroeder
  • 123,438
  • 55
  • 284
  • 319
1

One of the principles of secure programming is to give the user the least amount of information possible on a error message. Only show the timestamp if the user needs to know it.

I don't see any use of a timestamp on a user facing error message, so I would leave it out.

A timestamp can be used on a side-channel attack trying to bruteforce a password. It's very unlikely, very hard to do properly, but possible.

You can use a special var to show a detailed error with timestamps:

if (isset($_GET['is_debugging'))
   echo $timestamp;

This will only show the timestamp if the var is_debugging is defined on the query. The end users will (hopefully) not know about the var, and the devs can use it to debug.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • Agreed that the user does not need it. The developer also does not need it if there is an easy way to access the stacktrace for a given error-code. The grim reality is that right now our errors are distributed over several log files on multiple machines. It hopefully will change in near future, but until then the extra information is useful to locate the relevant files. Therefore, the old logging format included the time (but only as the day of the month). Having said that, I agree with you that with a state-of-the-art logging service, the error-code is not needed and any unique id is fine. – Philipp Claßen Feb 04 '15 at 19:36
1

This information can be useful from a support perspective, so the user can open a ticket to you web shop and tell precisely when he encountered the issue described. Otherwise, trying to solve issues from users claiming to have encountered an error "last week tuesday morning... unless it was wednesday... actually maybe it was at the end of the afternoon instead...", you may end up loosing too much time investigating logs without knowing what, when and where to search.

A good alternative, IMHO, I see more and more often is to display a base64 representation of some encrypted data, telling the customer to send this data to the support center would he need some assistance (Google uses this system, an example can be found here). In this data, you are more free to put data which can help you to investigate the encountered issue without disclosing anything to the final user (and, as a bonus, it guaranty you that the user did actually encountered an issue...).

WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104