Is JSON the business of credential?
tjconcept opened this issue · comments
Is it really necessary to have the JSON.parse/stringify business in this module? It seems rather arbitrary to me. If using a store like MongoDB it makes little sense to save it as a string - and then I would be able to do lookups of potentially weak passwords (in the sense of iterations).
If it's an interface thing, we might just as well use array.join and string.split - not that that's any better.
A backwards compatible approach might be to return the object, but attach a prototype with a toString method that's basically JSON.stringify. It would be fairly easy to have verify support both formats. Of course I'd rather see a breaking change and complete strip of the stringifying and parsing.
My thinking was that if we leave JSON handling in userland, that's a potential attack vector if the library user screws it up. I'm not entirely convinced that I didn't screw it up, though. Particularly for the parse errors case.
I'm open to reversing course on this issue.
JSON.parse should always deal with "own" data, so I don't think error handling is necessary.
You're right, it is a potential user-screw-up.
I guess I think, there should be a really easy API, that suits 90 % of users, including those, that don't want to read more than the first two examples - like the current does.
I think it's more a naming thing to me.. The .hash method returns something that isn't really a hash, looks like an object, but is not, but can of course be used like an old-day hash.
Another method (documented last) could be returning the object, and .hash could simply be wrapping this with stringify.
By the way, I'm sorry for being this eager to do all kinds of changes, breaking and not 😛 I just really want a proper secure module without oddities to put in my node-toolbelt.
I think it's more a naming thing to me.. The .hash method returns something that isn't really a hash, looks like an object, but is not, but can of course be used like an old-day hash.
"Hash" in this case refers to the one way cryptographic hash, not to the return value. I don't think this will be very confusing to JavaScript developers, because JavaScript doesn't have a "hash" data type. Key / value objects are usually called "objects" or "maps" in JavaScript rather than "hashes".
BTW, this would be a breaking change, so we need a more compelling reason than "gee, it would be nice if this returned something different". The only reason I'm even willing to consider this one is because currently, it could potentially return an error, instead of the expected object, and that could be a (potentially serious) security problem if users of the lib fail to check for the error case.
I think using a stringified JSON is just fine. By definition it's just a string, you shouldn't care about its content. Strings are easy to store, JSON is supported by the language, we don't have to invent our own serialization format.
I still think we need better handling for the error case.
Agreed, let's close this for now.
I'll do a JSON.parse/stringify in my application for now.
👍
Looks like I was worried for no reason anyway. Credential already behaves appropriately if the stored hash can't parse correctly.