Of course, the support portal requires you to auth to use it...to get help with auth failing.
Anyone else seeing issues getting in to their dashboard?
Edit: Auth started working for us and dashboard access became available for us around 5:15 pm ET.
The login issues are unrelated to the security incident. We notified all of our customers and users concurrently resulting in a spike in login attempts. Please try again in a few minutes if you are still having trouble logging in.
Please continue to monitor our alerts page: https://www.mongodb.com/alerts
I'm trying my personal account as well and it's telling me MFA isn't set up (it is) and it's making me go through the MFA setup flow again. All attempts to setup another 2FA code in 1Password or to get even an SMS code sent to my phone are failing.
Edit: Personal account with a TOTP 2FA is working again now as well.
This is feeling worse than they're letting on to.
I like this tbh and I hope people won't punish them for not including more info when this is clearly in the early days of investigation.
I want answers.
I'm sure they want answers too, but they're working on it, and this is what they have right now.
You do not have the option of (C) Vendor should tell me about a breach they don't yet know about.
For all the shit MongoDB gets, this is something that people should take a step back and recognize as very high in integrity, transparency, and trust.
Other businesses should follow their lead here.
I'm more inclined to do business with MongoDB because they've demonstrated these principles first-hand.
Is there some context I’m missing, or is this a modern security team recommending password rotation?
More independent MongoDB DBaaS providers is what would offer true redundancy in this case, though it is highly restricted due to SSPL license change.
Hopefully FerretDB will be successful building feasible alternative
What did not happen (yet) is complete AWS meltdown
Hi Redacted,
MongoDB is investigating a security incident involving unauthorized access to certain MongoDB corporate systems. This includes exposure of customer account metadata and contact information. At this time, we are NOT aware of any exposure to the data that customers store in MongoDB Atlas.
We detected suspicious activity on Wednesday (Dec. 13th, 2023) evening US Eastern Standard Time and immediately activated our incident response process. We are still conducting an active investigation and believe that this unauthorized access has been going on for some period of time before discovery. We have also started notifying relevant authorities.
What should you do next? Since we are aware that some customer account metadata and contact information was accessed, please be vigilant for social engineering and phishing attacks. If not already implemented, we encourage all customers to activate phishing-resistant multi-factor authentication (MFA) and regularly rotate passwords. MongoDB will continue to update mongodb.com/alerts with additional information as we continue to investigate the matter.
Sincerely, Lena Smart MongoDB CISO
- 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 no concern over injection attacks (you have to go out of your way to create potential for them).
- Easier to write non-trivial queries than with SQL (IMO).
- Type-casting data can be done in code as opposed to with SQL you have to use inline, platform-specific functions like field_name::timestamp.
- A single source of truth for how to query and develop with it (with SQL, you're almost always developing against a flavor of it).
- Scales reasonably well (and easily) for a majority of use cases.
- No room for dogmatic fervor/confusion around a specific variety of MongoDB as there's only one variety.
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.
At first at least, haven't checked in on that in awhile
In 99% of the cases, even if you need a flexible schema, PostgreSQL will remain the best choice.
Note: I work at MongoDB
Isn't firebase built on top of mongoDb?
This is not easy to do with PostgreSQL, which we use for all other scenarios requiring a DB.
For now, there are way too many critical issues found late in the release cycle.
I think it only hurts people who want to freeride the project and extend it for selfish personal gains. That's OK by me.
For this reason, there are many providers to choose from, and there is a healthy amount of innovation and competition in the space. Prices are set by market and demand, as it should be.
And then there is MongoDB where only a handful of providers could negotiate a license, and the price is set by MongoDB Inc.
In my opinion this is by no means "fine" from a user perspective as we are talking about database software.
If anyone did freeriding, it is MongoDB Inc. who chose to freeride on the open source community for marketing purposes, before switching to SSPL.
[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
[2] https://opensource.stackexchange.com/q/13888
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915537
[4] https://fedoraproject.org/wiki/Changes/MongoDB_Removal
[5] https://bugzilla.opensuse.org/show_bug.cgi?id=1122267
[6] https://lists.archlinux.org/archives/list/arch-dev-public@li...
I am not sure really.
"It should be noted that the new license maintains all of the same freedoms the community has always had with MongoDB under AGPL - they are free to use, review, modify, and redistribute the source code. The only changes are additional terms that make explicit the conditions for offering a publicly available MongoDB as a service.
Obviously, this new license helps our business, but it is also important for the MongoDB community. MongoDB has invested over $300M in R&D over the past decade to offer an open database for everyone, and with this change, MongoDB will continue to be able to aggressively invest in R&D to drive further innovation and value for the community."
We built an email service (IMAP support added a month ago) and wrote a WebSocket to SQLite layer to solve our encryption at rest needs for storage.
See our deep dive at https://forwardemail.net/blog/docs/best-quantum-safe-encrypt... for insight.
Kind of makes me unsure if it’s going to be the right choice.
Just pick postgres. If you have unstructured data as input, either put in the effort to create some kind of schema for it if you can or just use jsonb if you can’t.
Are you basing this opinion on:
- popular HN opinion
- issues that Mongo experienced in its infancy
- mis-modelling highly relational data on a non-relational DB, and blaming the DB for ensuing problems
Or are you basing it on extensive experience with wide range of use cases?
