Certainly is enforceable, there are two clear scenarios that come to mind immediately (there may well be more):
1. A hacker gets into your system, and publishes a complete dump of your database. 2. Suspected crime, and a government agency (with appropriate warrant) gets a copy of your database. In both cases your database is no longer in your hands, and your password policy is on display. The very least you should do is store password hashes, which provide at least some minimal security both for your users and CYA. On Wednesday, 16 January 2013 16:19:34 UTC+1, rakesh mailgroups wrote: > > tomorrow I decide to build a website that takes credentials. > > I don't see if I choose to store the passwords or not, encrypted or not, > is governed by some law. Its not enforceable. > > Obviously, as a professional, I would want to make sure the decision I > make does not lead to issues with my business. > > When Sony was hacked, no government prosecuted them (I believe). > > Rakesh > > > On 16 January 2013 12:06, Ryan Schipper <[email protected] > <javascript:>>wrote: > >> Definitely the more purist approach. Less value for investigations. >> >> In reality, Most organisations choose to take the chance on this in order >> to assist investigations when necessary >> >> Smart software could also check whether the username is valid prior to >> including it in the log. Though this could open the possibility of timing >> attacks. The whirling dervish of security strikes again.... >> On 15/01/2013 10:13 AM, "Josh Berry" <[email protected] <javascript:>> >> wrote: >> >>> I thought it was actually best practice to not even record the >>> username. Since a very conceivable mistake is to forget to tab over to the >>> password field and then submit the form after typing username and password >>> into the same field. Perhaps only storing a hash might be safe. >>> >>> Regardless, does seem in the questionable category of even being useful, >>> and instead just opening you up to further attacks. I view it (in what I >>> do not think of as a controversial view) as the username/password of users >>> is actually valuable information. As much so as credit card numbers. >>> Treat it as such. >>> >>> (None of this is to say Ryan's answer is incorrect in any shape form or >>> fashion.) >>> >>> >>> On Mon, Jan 14, 2013 at 5:16 PM, Ryan Schipper >>> <[email protected]<javascript:> >>> > wrote: >>> >>>> As to the legality, I think the correct question is: is it legal to >>>> store the password (as entered or some derived form, such as a hash)? >>>> >>>> Auditing failed login attempts (the username, a timestamp, etc) is an >>>> extremely common practice - in fact, Australian information security >>>> standards require it and common professional security certifications >>>> (CISSP >>>> etc) recommend it. I'd be very surprised if it illegal to track this sort >>>> of information within the EU. These logs are invaluable in conducting >>>> internal fraud or security investigations. >>>> >>>> That said, why does the password (in particular) need to be tracked? I >>>> can think of a very good reason not to track it: mistyped passwords. >>>> Consider how many times you mistype your password. If a computer system >>>> were to track my mistyped passwords, the database containing those would >>>> become a treasure trove for internal fraudsters. >>>> >>>> I can't think of a sane security professional that would recommend >>>> tracking passwords in this manner - usernames and timestamps, absolutely, >>>> but not passwords. >>>> >>>> PS. As usual, if you or your client are legitimately concerned, you >>>> should be consulting a practicing lawyer, not a list of Java doods. =) >>>> >>>> -- Ryan >>>> >>>> On 15 January 2013 08:30, Fabrizio Giudici >>>> <[email protected]<javascript:> >>>> > wrote: >>>> >>>>> On Mon, 14 Jan 2013 22:24:35 +0100, Kevin Wright >>>>> <[email protected]<javascript:>> >>>>> wrote: >>>>> >>>>> That depends on what you mean by "retain". >>>>>> >>>>> >>>>> I suppose he means the credentials are logged, or stored somewhere not >>>>> just in order to re-render a page. >>>>> >>>>> -- >>>>> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. >>>>> "We make Java work. Everywhere." >>>>> http://tidalwave.it/fabrizio/**blog<http://tidalwave.it/fabrizio/blog>- >>>>> [email protected] <javascript:> >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Java Posse" group. >>>>> To post to this group, send email to [email protected]<javascript:> >>>>> . >>>>> To unsubscribe from this group, send email to javaposse+...@** >>>>> googlegroups.com <javascript:>. >>>>> For more options, visit this group at http://groups.google.com/** >>>>> group/javaposse?hl=en <http://groups.google.com/group/javaposse?hl=en> >>>>> . >>>>> >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Java Posse" group. >>>> To post to this group, send email to [email protected]<javascript:> >>>> . >>>> To unsubscribe from this group, send email to >>>> [email protected] <javascript:>. >>>> For more options, visit this group at >>>> http://groups.google.com/group/javaposse?hl=en. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Java Posse" group. >>> To post to this group, send email to [email protected]<javascript:> >>> . >>> To unsubscribe from this group, send email to >>> [email protected] <javascript:>. >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Java Posse" group. >> To post to this group, send email to [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to >> [email protected] <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> > > -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/XAIX9KBuS8cJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
