Have a look at this, it's actually quite descriptive: https://mega.nz/SecurityWhitepaper.pdf Also mind you the link you mentioned is over 7 years old, things will have changed since then.
How do they verify that the user enters the email / password correctly? While login information is sent to the server only email address.
When you create your account, you send information to the server that can be re-calculated using your password. As far as I understood from the documentation, when you login, a string is calculated from your password that is sent to the server as form of authentication token to be matched on their side. Something akin to sending the password for them to compare the hash, except the hash would have been calculated on the client side (this is not accurate, just a simplified example). If you don't always have to enter your password, that's because you're caching this authentication token.
I think they store the encrypted password or the key to decrypt the password as plain text or vice versa to check if the user information is entered correctly or not? And I noticed that every time I log in successfully, the server sends me the same mega decryption key, if both the password and the decryption key are encrypted on the server, how do they send the decrypt key has been decoded for me?
Your question is a bit confusing. And I am not aware of the implementation details of mega, so I may be off the mark here. * It is possible that the service sends you AES keys for handling your files, although I find this simplistic and unlikely. Moreover it is also unlikely (and unnecessary) that they would hold this key in plain text; * They almost certainly do not hold a cleartext version of your password. There's no reason to do that; * It is possible that they hold copies of encryption keys in such a way that they can't be used to decrypt your files. Using asymmetric cryptography you are able to pull in the encrypted AES key and decrypted with key material that only you possess (calculated at the time of registration). Also notice that you would be dealing with multiple AES keys, not just one; * It is possible to have the system built in such a way that they are physically unable to decrypt your files simply because they do not have enough key material to do so. Ever. This is called zero-knowledge encryption and is incredibly rare and tricky to implement correctly; Boxcryptor and Spideroak aim to do exactly this and as far as I understand have got the right concepts in place. Check out their documentation.
As far as I "understand", they use AES to encrypt most of the data, RSA just to create shared links (to people, emails, ...) and encrypt messages.
AES to encrypt information. RSA to securely exchange keys. Shared links are probably generated out of random data, it does not need to be decoded or decrypted, just very difficult to guess.
In particular, the user password will act as the key to decrypt the user data (files, folders, ...) encrypted AES so the user password will be saved as plain text on the client or server can be used to decode their data?
Generally user passwords are used to calculate "data" using algorithms like PBKDF2, etc. But rarely is this material used as keys directly, since otherwise you would not be able to change passwords or else the keys would change and you'd loose the ability to decrypt your information. There is never a requirement to store passwords in plain text anywhere.
If user passwords are used to decrypt their data, what is the key to decrypt their passwords? Created when? Where to be stored? And is it encrypted?
In order to securely share encrypted data, you need to use unique AES keys that are then shared to the list of recipients you assign. To distribute this key securely, you'd need to use their RSA asymmetric keys.
For example Data1 to be shared with users 1, 7 and 9 is encrypted with key AES1 [let's call it AES1(Data1)] and sent to each recipient respectively encrypted with their RSA public keys [RSA_P1(AES1), RSA_P7(AES1), RSA_P9(AES1)]. Each recipient is able to decrypt the AES1 key by applying their private keys [AES1=RSA_p9(RSA_P9(AES1))] thus being able to decrypt AES1(Data1) since Data1=AES1(AES1(Data1)).
