ISP is not hashing the password I log in with online. Should I take any action? I just phoned the customer support number for my ISP for the first time and was surprised to be asked the fourth and fifth characters of my password, specifically the one I used to log into my account on their website, not a special password for use over the phone. The fact that they know what the fourth and fifth characters are shows that they are not hashing the password. I believe the GDPR requires them to store the password securely, and if they're not hashing it then I'm sure it can't be considered secure, so should I report them to someone? The only thing that makes me think this might be acceptable is that it's common for organisations to ask for certain characters of a password over the phone. I think they normally set up a different password specifically for this though, rather than using the website login.
The GDPR does indeed require that the password be stored "securely". It does not specify the technology which must be used for that purpose. Hashing the PW is a common method, and should be sufficient if properly implemented (strong hash function, use of salt, etc). But other methods of securing the password might be sufficient. Encrypting the PW rather than hashing it, so that an authorized person could decrypt it temporarily might be OK. Or perhaps a security app can separately retrieve only the specified characters of the PW through some sort of encryption. Or perhaps the ISP is not using proper security. In the case of Knuddles in the linked news story, an actual breach occurred which led to the poor security being reported. You could send a report to the appropriate national Data Protection Authority.
If you merely provide software for your client to use, you are not processing personal data on behalf of the client. But if you have access to systems that store personal data, then you must consider the GDPR. Or more accurately: your client must consider the GDPR. Under what legal basis can they give you access to the data in these systems? The easiest way to solve this is indeed if you act as the client's processor. Processor status is never the default, but requires a binding contract with the data controller. This contract will require you to only process personal data as explicitly instructed by the client, and may require you to take certain security measures as a precaution. Without such a contract you aren't a data processor, but possibly a data controller of your own (with all the compliance obligations that implies).
Much of your ability to sue the email company for damages depends on local and Estonian laws, but the most important aspect is the TOS and user agreement you agreed to when you originally signed up for the service. Read it (though if the portal is now off-line, it may not be accessible). You may have agreed to hold the company not liable for any damages from loss or stolen data, and you may have also agreed to arbitration and to not pursue them in court. It all depends on what is (was) in that agreement, so find a copy of it; though it's possible that some local or Estonian laws may supersede any contractual agreement with the company. And FYI, the email you received concerning the video and demanding payment in Bitcoin is a common scam right now, and the threat may indeed be meaningless.
They are probably not required to provide online access at all. They are probably required to provide some sort of written statement, unless you have waived that in favor of online or electronic versions. The exact requirements will vary in different jurisdictions.
Yes, but it doesn't matter. This answer discusses gdpr implications. Personal data is any information that relates to an identifiable person. The GDPR has an extremely broad concept of identifiability, also covering indirect identification using additional information and with the help of third parties. Even just being able to single out one data subject, i.e. being able to distinguish different users from another, counts as identification. If you already have a concept of user accounts, any information that is linked with the user accounts and somehow relates to those users would also be personal data. Since you have distinct push tokens per user, it seems like this criterion would be met. Additionally, those unique tokens might be directly identifying by themselves. The GDPR does not allow for semantic games like “it only identifies the device, not the user”. The key here is that the definition of identifiability does not hinge on your intentions, but on objective capabilities: if you or someone else who can come into possession of this data were to attempt to identify the user (such as singling out users from another), would they be reasonably likely able to do that? Since most devices are single-user, being able to identify a device would imply that you're reasonably likely to also identify users. Just because something is personal data doesn't mean you're forbidden from using that data. It means that you'd have to comply with GDPR rules, if you're otherwise within scope of that regulation (e.g. if you're EU/UK-based, or are targeting your services to people who are in UK/EU). For example, basic GDPR compliance steps include having a clear legal basis for your processing of personal data (such as necessity for performing a contract to which the data subject is party, or necessity for a legitimate interest, or consent), providing a privacy notice, and taking appropriate technical and organizational measures (TOMs) to ensure the compliance and security of processing. For example, TOMs regarding these push tokens could involve encryption, access controls, and a plan for installing security patches in order to prevent data breaches. Using push tokens is already a good measure in this context, since they are effectively pseudonymous and prevent linking additional information via that token (two sites/apps pushing notifications to the same person will have entirely different tokens). However, the push notification provider (e.g. Google, Apple, Mozilla) can resolve the pseudonymous tokens and link them to a person, indicating that these tokens are ultimately identifying (even if you can't perform that linking yourself). Note that if GDPR applies, then other EU/UK rules might apply as well. For example, sending electronic messages (such as emails) is subject to anti-spam rules (EU: ePrivacy, UK: PECR). These rules apply regardless of whether personal data is involved. Since the rules are not technology-specific, it is likely that regulators would consider user-visible push notifications to be equivalent to more well understood technologies like email and SMS.
In the question, you write: The GDPR requires consent of the subject for collection or storage of personal data (in this case, IP addresses in a log file). No, it does not. To quote Miss Infogeek: GDPR DOES NOT MAKE CONSENT A MANDATORY REQUIREMENT FOR ALL PROCESSING OF PERSONAL DATA. Consent (Article 6 (1)a) is indeed one of conditions that can be used to comply with the GDPR requirement that processing must be lawful, but it is not the only condition available to the controller to ensure lawful processing &ndash; there are alternatives (before the list of conditions it says that "at least one of the following" must be satisfied). All the conditions for lawfulness of processing are spelled out in Article 6 of the GDPR. One of alternatives are Article 6 (1)f. It says says it is legal to process personal data if processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. (my emphasis) As noted in the question, logging IP addresses for the purpose of security is an extremely widespread practice. It is a legitimate interest to comply with standard security practices. It is the default, and most (all?) web-sites do this. I.e. it is legal to do this without consent (if this is not the case, I am pretty sure the outcry had been heard all over the Internet by now).
The intention of the GDPR is to minimize the amount of personally identifiable information (PII) you store. So the GDPR never tells you that you have to log certain events. The simplest way to make sure you comply with the GDPR is to simply not store any PII at all. But that might of course conflict with legitimate business interests and with other legal obligations you might have. So when you do store PII, then the GDPR regulates under which conditions you are allowed to store PII, for how long and what you are allowed to do with that PII. So when you receive a GDPR request from a customer to see their data, then you can say that you only have that one timestamp of their registration, because you didn't log their subsequent logins (assuming this is the truth). I hope your privacy policy says that you store all that PII on registration and that you have some good arguments why storing that information is a &quot;legitimate interest&quot; of your organization.
It isn't necessarily "illegal" (in the sense you are committing a crime) but you may be in violation of a verbal contract (which would fall under tort law). Let's take this a bit further. Perhaps Joe Schmoe gave you his debit card information so that you could make deposits for him and he said you could take $5 out for yourself for the trouble. This is a contract between you and Joe for a service. You can't extend Joe's offer to Jane Doe by saying "here is some debit card information, take $2.50 out for yourself". You have no right to extend your contract with Joe to somebody else. Now specifically for passwords it basically boils down to the same thing. Unless Joe gives you explicit permission to give that to somebody else, you can't just decide to unilaterally give what Joe gave you to somebody else. This may be different if Joe said "here, I'm buying you a subscription to service XYZ because you are a nice guy", this may be construed as a gift which transfers ownership. At that point you have control over what is or isn't done with the account. As another example let's say Joe let you borrow his car. You can't turn around and say to Jane, "here's a car you can use", Joe did not extend the offer to Jane, nor did Joe give you the right to extend the offer to another person. It's a moot point though, in the original context of this question, Netflix does restrict you from sharing your passwords "outside your household". Almost every paid service has some restriction against sharing with others. In the end Netflix may shut off Joe's account and Joe may sue you for damages, but you aren't going to be thrown in jail for this. This would be a civil case (tort) which you may be liable for monetary damages.