> > - alternatively, sketchy home-grown AES-CBC crypto that doesn't seem to be authenticated and as such allows for replay attacks and whatnot
> Yup,home grown sounds kinda bad but I don't see the problem if they just replicated the process with their own code without modifying how it works and avoid IV reuse.
> > - home-rolled SHA-1 pbkdf1 instead of stdlib pbkdf2 with a better hash
> Same as before.
For both of these, my general thought is that they're massive crypto code smells - implementing things yourself when a vetted library exists is just not something you do for secure code. If we can see these crypto issues already, there's going to be more. Maybe it'll be implementation bugs, maybe conceptual architecture issues - but I'd bet on this not being a complete list. So even if these bugs aren't exploitable they're indicative of something deeper.
> Yup,home grown sounds kinda bad but I don't see the problem if they just replicated the process with their own code without modifying how it works and avoid IV reuse.
> > - home-rolled SHA-1 pbkdf1 instead of stdlib pbkdf2 with a better hash
> Same as before.
For both of these, my general thought is that they're massive crypto code smells - implementing things yourself when a vetted library exists is just not something you do for secure code. If we can see these crypto issues already, there's going to be more. Maybe it'll be implementation bugs, maybe conceptual architecture issues - but I'd bet on this not being a complete list. So even if these bugs aren't exploitable they're indicative of something deeper.