app logins

[David Schwartz 426]

I'd like to hear people's thoughts about this topic.

 

I'm working with TMS WebCore and their MyCloudData to prototype something. There's a kind of utopian idea that you can "build once, deploy anywhere", but there's a fly in the ointmen that nobody seems to talk about.

 

It seems to me that web apps come in two flavors: open and accessible to all that don't tend to save data; and everything else that lets you do stuff and save data across some notion of "sessions".

 

The former might delivery kind of utility, like prettyprinting code or translating data from one format to another. The latter is what I'll generically refer to here as a "membership site". (Perhaps another terms is more appropriate; this is just how I think of them.)

 

Historically speaking, desktop apps had no form of "login" -- they relied on the fact that there was a login on the computer, and assumed anybody who could get on the computer was permitted to access the software on it. This assumption still lives today on desktops as well as mobile devices. Which means you cannot simply take a desktop app that saves user data and drop it on a website to turn it into a web-based app. 

 

A lot of existing apps DO, in fact, offer if not require you to login, and there are a lot of reasons for that besides allowing you to keep your saved data separate from others. One big reason is to access walled-off services that require a paid subscription to allow access, for example. (At the very least, a registration is required in any case.)

 

The thing is, the front-end or web-app could use something like OAuth2 to verify your login. If it's simply to gain access to some stuff kept behind a paywall, that's fine.

 

But what if it uses your login to partition your data from everybody else?

 

Back-end services typically have a login; in many cases, they're used by the developer or vendor to ensure nobody else can use the resource(s).

 

For example, if my app uses SQL Server or MySQL, I have a login that all of my apps probably use to access my DBs. They may all share the same credentials. But they're MY credentials, as the developer.

 

What about the users? How deep do you push the use of user credentials? The user could login just to prove they have a current account, then everything else could be done with MY (developer's) credentials.

 

If you need HIPAA or PCI compliance, tho, I'm not sure that would fly.

 

I'm wondering about this b/c I work in an environment now where user credentials go all the way down to the bedrock for desktop stuff. I'm not sure about our web tools, except they do require logins that are integrated into our single-sign-on protocols.

 

I can see that a lot of services my software might access do not need to be partitioned for use by each user with their own credentials. But, in some cases, they might.

 

So let's say you have an app and it requires a login to access and maintain some personal (but not very sensitive) data, then it can drop a cookie (in the web-app case) that, say, lasts a month. (I see this on lots of my phone apps.)

 

The login controls access to some common data as well as a limited set of personal data. 

 

This isn't how Desktop apps normally work -- Windows or MacOS or *nix logins run the show in most cases. I'm not sure about mobile apps. Web apps designed like Delphi apps are still rather new. (Any IntraWeb users wanna chime in here?) 

 

But you don't design php or Wordpress sites as if they're Delphi apps. (In Wordpress, everybody gets a login, but the underlying resources all rely on a common access login. Strangely, it's common for membership sites that run inside of Wordpress to have a completely separate way of  managing users rather than using the logic built-in to Wordpress. I think that's because the membership sites want more meta-data than WP can collect on its users.)

 

What do you do when you can build web apps in Delphi that can look and feel more like normal Delphi desktop apps? (I'm not says they MUST or even should, only that they can.)

 

Have you given this any thought? If so, I'd love to hear your ideas.

 

 

Edited May 23, 2020 by David Schwartz

[Fr0sT.Brutal 900]

Honestly didn't read thoroughly - too much text. If you've got to store some user-related data then you have to use accounts. Or you may save things in local storage but it has drawbacks

[stijnsanders 35]

I've given this quite some thought. I've made a list once here (it's in Dutch though) what you should do if you want a full fledged account management platform with login, and that's even before GDPR, and not handling what's available from other platforms, e.g. with OAuth or identity services from cloud providers that are available nowadays. I haven't worked with IntraWeb or TMS Web Core, but I've dabbled with a Delphi-(compiler-)based web-platform of my own, with an explicit emphasis on speed, security and portaility (between hosting environments), so yes if you want to build something serious you need user control and it takes some work. For a first big xxm application/website of my own: tx I for now stick to this list I created of everything I think a website with user accounts should have. But for new websites it's increasingly interesting to skip the hard work and make your website depend on a number of options you can expect your users to have an account with: Google, Facebook, Twitter, Microsoft, and if your public is somewhat tech savvy Github. (I should check if reddit has an OAuth api...)

[Guest]

I designed few applications over years, and still maintaining two of them, and i want to share few security and privacy points to consider than make sense for Server/Client apps as for web apps too.

 

1) Login per user is central, one can't do much about that, but no plain passwords is sent over wire, instead some hash (or obfuscated unique value derived form the password ) will be send.

2) User valuable data ( privacy and high profile information, eg. address, payment cards, etc. ), those data are stored encrypted on server side or on the cloud, and by encrypted i mean encrypted the right way, so server can't read and parse them without the decryption key, here the decryption key is something else from the password hash ( unique value for login along side the user name mentioned in "1" ) , in some cases i even used PKI for that, so the client generate public and private key where the private key is derived from his login and password, then send his public key to server to be stored in plain and accessable way, server in this case can only encrypt data and assign it to the user account, server will never be able to decrypt those data saved by itself or sent by the client to be stored.

3) Changing use password is the challenging thing in such design, as it would require client to to use its old and new password ( and its derived) to decrypt then encrypt all of the data assigned to its account, for that i limit the changing the password to one per 5 minutes, and the user directly after that should be kicked out ( logged out), before server will perform that data re-encryption.

 

The whole idea is this : if you have the server itself and you have the database with all stored data by the whole system, then you have nothing without the client passwords, even if the server itself will handle parts of encryprion/decryption, but he will do it when the user is online only, so no bulk data leak.

 

One theing left to mention about that, the problem from logging, as it is essential process for any application that dealing with high valuable information ( money !) , logging is encrypted in very similar way but using fixed public key supplied by the administrator of the system where the private key is not allowed near such server, i usaully send the log of such server to another location and if server is not online with its log receiver then it will stop serving any client and notify the administrator.

 

Another thing to mention : to prevent data injection from server side by intruder, all encrypted data should have some sort of mechanism to validated/authenticate the decrypted data by the client, and because server side has the user plain public key, the data only will be stored accoring specific structure with specific hash/nonce derived from the account name, and here i use TOTP key generated by the user and stored in different server/cloud location, so for intruder to successfully inject data for a client he must have access to two separated storage, and here all what he can is inject data ( delete is an option all the time), why data injection is high risk, take this example: the system has internal messaging system ( may be some notification in web app) so the server will generate the message and store it where client will see it ( receive) when goes online, so intruder can inject a message ( notification ) with a link to phishing site or to download malicious software of somesort instead of reciept.

 

[David Schwartz 426]

18 hours ago, Fr0sT.Brutal said:

Honestly didn't read thoroughly - too much text. If you've got to store some user-related data then you have to use accounts. Or you may save things in local storage but it has drawbacks

This is what Wordpress does ... which I addressed. Seems in your hurry, you have nothing to add. Better off just moving on next time.

Edited May 24, 2020 by David Schwartz

[David Schwartz 426]

@stijnsanders and @Kas Ob. -- I appreciate the depth of your replies, but in this case there's nothing really on the server that's personal other than when a user subscribed, for how long, if they're still active, and their renewal rate, along with their first name, pwd hash, and email address. I suppose I could encrypt that stuff, but it's not particularly sensitive. However, the front-end needs to read some of it -- in particular, the FE needs to know if a visitor is a currently active subscriber, and possibly if their subscription is close to expiring so they can renew it. Is any of this a problem with GDPR?

 

I do like the idea of validating using a 3rd-party login like FB, Twitter, etc., as an option. I'll look into that. I imagine it puts the onus of user validation on these other systems, right?

[Attila Kovacs 629]

https://lmgtfy.com/?q=GDPR

[Guest]

3 hours ago, David Schwartz said:

Is any of this a problem with GDPR?

No, that is not a problem, assuming here you have a EULA that the subsriber had accepted in order to register and became a subscriber, in that EULA you explained you will save his credintial ( and his information, eg. full name, interest..) and how the site will use them , right ?

if yes then you are OK, for other visitors that are non subscriber, do you ask for there names ? of course not, then you are OK with that too,

now the question is do you use cookies to identify the non subsecribers ? that is problem and that what do need new and separated EULA assigned to that cookie, like almost every site nowadays.

 

3 hours ago, David Schwartz said:

I do like the idea of validating using a 3rd-party login like FB, Twitter, etc., 

Not a fan, as this will obligate you to update your EULA to your users ( visitors) to be updated every time that 3rd-pary updated his.

3 hours ago, David Schwartz said:

I imagine it puts the onus of user validation on these other systems, right?

This will complicate things as those GDPR compliance requirements is not a simple delegate-them-to-3rd-party and you are free, it is your site and your users (visitors) then it is responsibility, please read more and do your diligence, i don't have enough information on this subject, but someone here might have more knowledge and can explain this to all of us.

[Anders Melander 1783]

1 hour ago, Kas Ob. said:

No, that is not a problem, assuming here you have a EULA that the subsriber had accepted in order to register and became a subscriber

One important thing to keep in mind is that once a customer (i.e. a subscriber) becomes a non-customer, then you have to get rid of any identifying data. Anonymizing the data is Okay.

Basically you must not store any personal data that is not vital to servicing the customer. Even if the data is "nice to have", might come in handy or whatever.

 

3 hours ago, Attila Kovacs said:

https://lmgtfy.com/?q=GDPR

Exactly. GDPR is not something you ask to have explained in some forum. You need to read up on and understand the issues involved because it's your responsibility to make your software compliant.