Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB security notice

mongodb.com

Post reply on HN
Print view View original

141–150 of 198 posts

Re: MongoDB security notice

#141

Post by winrid »

djrobstep wrote: post #134
rglover wrote: post #131

Earlier quoted context omitted.

- Highly-flexible. Because you're not developing against a schema, you can, for example, retool a feature and its data quickly without having to stress about migrations. A big advantage for a startup looking to move fast. - Queries look more like application code so you're not wasting mental cycles and time trying to translate an idea into a SQL query. From experience, this leads to less-fragile queries. - Little to…

> Because you're not developing against a schema, you can, for example, retool a feature and its data quickly without having to stress about migrations. A big advantage for a startup looking to move fast. Why wouldn’t you need to worry about migrations without developing against a schema? You’ll need to worry more about migrations because your data will be more messy.

It could be rephrased as "worry about them later" :P gotta get those returns on the VC money and pawn those issues onto the next team in 7yrs :)

Re: MongoDB security notice

#143

Post by winrid »

cpursley wrote: post #124
tgv wrote: post #53

Earlier quoted context omitted.

I use it on-prem (well, on a VPS). It stores JSON documents, and it's easy to work with. If your data looks like a tree, it works pretty well, also for large documents. If you depend on relations between documents, you're better off with an SQL database, but note that for many cases --I'd say practically all mundane cases-- there's really no need for relations the SQL way. MongoDB also does relations, but a bit more…

Postgres does all that plus 100x.

But the horizontal scaling is easier with Mongo than Citus.

Re: MongoDB security notice

#144

Post by twisteriffic »

richbell wrote: post #140
jhardy54 wrote: post #98

> […] regularly rotate their MongoDB Atlas passwords Is there some context I’m missing, or is this a modern security team recommending password rotation?

Regularly rotating secrets for applications is good. Forcing users to regularly rotate their passwords is not so good.

Correct! NIST recommends against forcing password expiry unless the password is known to be compromised.

https://pages.nist.gov/800-63-FAQ/#q-b05

Re: MongoDB security notice

#145

Post by sigzero »

belter wrote: post #97
Salgat wrote: post #83

Earlier quoted context omitted.

Yep, Jepsen has not only confirmed but later reconfirmed that MongoDB has for many years been on par with other NoSQL databases when it comes to transaction guarantees and data consistency.

Er...no.... "Jepsen Disputes MongoDB’s Data Consistency Claims" - https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/

That is 3 years old.

Re: MongoDB security notice

#146

Post by rglover »

djrobstep wrote: post #134
rglover wrote: post #131

Earlier quoted context omitted.

- Highly-flexible. Because you're not developing against a schema, you can, for example, retool a feature and its data quickly without having to stress about migrations. A big advantage for a startup looking to move fast. - Queries look more like application code so you're not wasting mental cycles and time trying to translate an idea into a SQL query. From experience, this leads to less-fragile queries. - Little to…

> Because you're not developing against a schema, you can, for example, retool a feature and its data quickly without having to stress about migrations. A big advantage for a startup looking to move fast. Why wouldn’t you need to worry about migrations without developing against a schema? You’ll need to worry more about migrations because your data will be more messy.

> Why wouldn’t you need to worry about migrations without developing against a schema? You’ll need to worry more about migrations because your data will be more messy.

If you're careless with your data, yes. "With great power comes great responsibility."

Re: MongoDB security notice

#147

Post by rglover »

winrid wrote: post #141
djrobstep wrote: post #134

Earlier quoted context omitted.

> Because you're not developing against a schema, you can, for example, retool a feature and its data quickly without having to stress about migrations. A big advantage for a startup looking to move fast. Why wouldn’t you need to worry about migrations without developing against a schema? You’ll need to worry more about migrations because your data will be more messy.

It could be rephrased as "worry about them later" :P gotta get those returns on the VC money and pawn those issues onto the next team in 7yrs :)

Not necessarily. If you're utterly careless, sure. A MongoDB migration is far less of a headache than a SQL one (you're just writing code to map/replace values). With SQL, you have to be frustratingly surgical about everything which can slow momentum to a crawl (read: punishment for mistakes in the migration is far worse than with MongoDB in my experience).

Re: MongoDB security notice

#148

Post by rezonant »

salil999 wrote: post #50
ThePowerOfFuet wrote: post #30

Earlier quoted context omitted.

You really should not be using SMS for 2FA.

For my own knowledge, if the options were between using SMS for 2FA or not having 2FA at all then what is better? I've heard mixed things about this.

Well a simswap attack requires the account password, since otherwise you would not be able to receive an SMS message for the two factor part.

But without two factor, only your account credentials are needed.

So yeah, it's definitely better than nothing, you are effectively forcing your opponent to social engineer your carrier, and doing that generally requires knowing the full number and usually at least your name, if not more identifying information that's harder to get, like social security number or equivalent.

Sure, TOTP or other two factor mechanisms are better because they require access to one of your authenticated devices (assuming the TOTP isn't done by a secure enclave), but SMS two factor is definitely better than disabling two factor.

Re: MongoDB security notice

#149

Post by rezonant »

wyldfire wrote: post #84
mtremsal wrote: post #59

Earlier quoted context omitted.

SMS 2FA is better than no MFA at all, despite the very valid concerns about SMS. It at least protects against credential stuffing and similar automated attacks.

I guess I've always cynically assumed that companies want my phone number to make the data they gather more valuable by making it easier to link with a unique index like a phone number.

Two things can be true at the same time.

Re: MongoDB security notice

#150

Post by rezonant »

iaresee wrote: post #62
speedgoose wrote: post #49

Earlier quoted context omitted.

But you have setup SMS 2FA enabled, which is convenient this time but a big security hole. You should consider disabling it once the situation comes back to normal.

> But you have setup SMS 2FA enabled No. I did not. Nor do I now. I had a TOTP setup in 1Password and Mongo was telling me MFA _wasn't_ set up and sending me through the MFA setup flow again. All options, SMS included, were failing in that MFA setup flow they pushed me in to. They're back now and my existing TOTP token is generating one time use passwords that work now.

I bet that's because different parts of their stack disagreed. Obviously a two factor setup should not be acceptable when one is already in place-- if the frontend thought it wasn't but the backend/auth services thought it was, it could explain that.
Post reply on HN