101–110 of 171 posts
That is an incredibly low friction interface to our documents. /s What are the odds they have access logs going back to 2003?
Pretty good, everything was probably set up and configured with default settings by that unpaid intern they had running their infrastructure back in 2003.
Earlier quoted context omitted.
Depending on how weak those credentials were, this sounds like something you should report to Krebs as well.
I mean the whole point of that company hiring someone to do a penetration test is to be sure this doesn't end up on Krebs. You pretty much lose your reputation if the company thinks you will go around and leak what you found out through that private investigation.
I did a penetration test for $NATIONALINSURER and they had an FTP site with weak credentials where all the remote offices uploaded claims. Millions of records and scans of SSNs, home addresses, bank information, etc. Their mitigating controls were: we put it behind a firewall. Then again I didn't expect much, their MSSQL in prod had SA/SA credentials active.
I've seen Retail stores with revenues in the 10s of billions using Telnet for the POS clients in 2019. They also used FTP glaore and were worried about the security of cloud. :)
EDIT: Oh, and the network controllers that ran them were uniformly updated and managed with fully open "admin" username no-password telnet and ftp services. IoT insecurity began a looooong time before the term IoT even existed.
Earlier quoted context omitted.
I once made an app not using sequential integers as object ids, as you suggest. It was an absolute nightmare. Maintenance was a nightmare, you're constantly having to generate or replicate these things that add an extra layer of complexity to everything, and almost always unnecessarily. It's also extremely bad for db performance, causes massive page fragmentation, indexes become useless almost straight after rebuildi…
I also don't think using UUIDs as a security (by obscurity) strategy is valid. But there are other reasons someone may choose to use UUIDs. For instance, it's convenient to generate identifiers in a decentralized manner. I want to counter your one bad experience with my (equally anecdotal) many-multiple good experiences. Databases do just fine with UUIDs. Though we may be working on different kinds of systems, and op…
> Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example.
HN discussion: https://news.ycombinator.com/item?id=10631806
Whenever you are compelled to upload/send a photocopy of an ID document it is sensible to write the date and purpose / file reference on it. If it appears in a document dump at some later date you know the path and date of the leak.
that is a good idea but most of the time I need to hand over my actual ID, and not just a scan of it
Yet another security vulnerability caused by: 1. Using sequentially incremented integer sequences as object IDs, and 2. Failing to protect sensitive data using some kind of authentication and authorization check. This is becoming a trend with data breaches. Several of Krebs' other reports on behalf of security researchers were originally identified by (trivially) walking across object IDs on public URLs. My cynical t…
I once made an app not using sequential integers as object ids, as you suggest. It was an absolute nightmare. Maintenance was a nightmare, you're constantly having to generate or replicate these things that add an extra layer of complexity to everything, and almost always unnecessarily. It's also extremely bad for db performance, causes massive page fragmentation, indexes become useless almost straight after rebuildi…
Yet another security vulnerability caused by: 1. Using sequentially incremented integer sequences as object IDs, and 2. Failing to protect sensitive data using some kind of authentication and authorization check. This is becoming a trend with data breaches. Several of Krebs' other reports on behalf of security researchers were originally identified by (trivially) walking across object IDs on public URLs. My cynical t…
I once made an app not using sequential integers as object ids, as you suggest. It was an absolute nightmare. Maintenance was a nightmare, you're constantly having to generate or replicate these things that add an extra layer of complexity to everything, and almost always unnecessarily. It's also extremely bad for db performance, causes massive page fragmentation, indexes become useless almost straight after rebuildi…
Whenever you are compelled to upload/send a photocopy of an ID document it is sensible to write the date and purpose / file reference on it. If it appears in a document dump at some later date you know the path and date of the leak.
that is a good idea but most of the time I need to hand over my actual ID, and not just a scan of it
Earlier quoted context omitted.
If you know the (integer) identifier, and because the bad application isn't secured with authentication, you get access to something you're not supposed to. If you make the identifier a lot harder to know, and you still have no security, that smells like the obscurity part. I can absolutely see your point that the UUID identifiers are not just a lot harder to guess, they may be impossible to guess. But the security i…
That's not what people usually mean by "security by obscurity" when they critique the concept. Unfortunately the term is overloaded so it's lost its way over time. To illustrate this for you, let me turn it around a bit. Is it security by obscurity if the only thing stopping someone from logging into your account is knowing your password? Security by obscurity is when you (for example) roll your own cryptosystem and…
That's been bouncing around at least since the time I noticed it on /. Which was a couple of decades ago.