Welcome to the mailbox.org user forum!
 

Device/App specific password

5512212 shared this idea 2 years ago
Proposed

It would be great to have an device/app specific password; otherwise one has to choose between security (using solely 2fa in the browser) and practicality (using email clients on laptop and phone).

Best Answer
photo

Yes, the main problem is our very high security level here. It would be very easy and mostly a no-brainer if we would use direct access to passwords in LDAP or a simple database. Other companies and people might do that -- we don't. People may believe that this looks supersecure -- but we know, how weak the protection of the password hash must be. We will not do this for marketing reasons, making people believing in bullshit and playing with their trust, fooling them about what's really going on the servers behind the scenes.

LDAP binds are very secure, because none of our systems has ACCESS to the password. But LDAP binds don't allow mutiple password attributes and you also don't have to select "which" password attribute should be used (to get something like app/service specific passwords that does not work on other services).

It would be easy to use multiple (app specific) attributes and the simple READ different attributes by every server. But then the password (hash) must be readable from our LDAP/database and all servers get access to it. This is what many people do (even if they have not implemented a multi-auth system).

As I said: Others might do that. Go there, believe in their security and believe, that this is much much much better. I don't have a problem with that, I can not make everybody happy, especially if they believe in marketing and not in technical reality and the deep, mostly hidden hard facts.

Implementing multiple passwords is on our roadmap, but the ways we have to go are much much much more complex, then normal. We first have to create an internal centralized single sign on solution, where afterwards all services can connect and approve internal access by tokens. For security reasons, also our internal systems are using credentials to get access to something. Our webmailsystem *must* have username/password to get access to the mail storage. (I've build hundreds and thousands of ISPs, normaly you use a readable standard-master-password, stored in the config of the webmailsystems. If somebody has the password, he can get access to all mailboxes from all users. That's how mostly everybody else outside there is doing it, even the "really big" ISPs. And then it's easy to implement different passwords, because the webmailsystem get's the webmail password from the user but must not have the real mail-password to do the forward connect to the mail backend -- it can use the master password.)

We have a many different internal services, every single instance here must be able to speak to the single sign on system here and to get/approve access by tokens. It would be very easy if it's just a webmail-frontend and just a mail-server. There would be just two instances if we would not authenticate every single service internally. Every API-call. Every management-glue-stuff. Every access in the user's setup page. And so on. But we do that.

Implementing a SSO could be done in days. But changing and implementing SSO in every single backend interface is a bunch of work. And the whole system is not ready to use until the last backend is able to authenticate.

Yes, we would/could be ready if we would not have done anything else in the last 9 month. But there's lots of work to do and my team did also many, many improvements behind the scenes to give mailbox.org a very stable, very scalable, very well structured backend infrastructure. Which is also very important for security. So we're started preparing everything for SSO, but we will start with SSO internally after everything was re-factured and moved to our new structure. We will complete that until end of year and new services are already prepared or alreasdy use something like internal-SSO. But it still needs time and we have made our decisions, what is really important and raises security for everybody. So I'm sorry, I have to ask for patience, we will keep on going doing everything in the right order.

But, yes: For sure we all have the same idea for app specific and service specific passwords. And we're working on it. For sure, I wanna have it, too. :-)

Comments (15)

photo
1

Deactivate 2FA. Connect via an email client to your mailbox account and then reactivate 2FA (working on Evolution email).

photo
1

Yeah, that trick doesn't work for me with K-9 mail IMAP, and it shouldn't work.

photo
photo
1

Deactivate 2FA. Connect via an email client to your mailbox account and then reactivate 2FA (working on Evolution as far as I can see).

photo
1

I agree with this proposal. I actually had already submitted this idea recently.

photo
1

If you go on Settings --> One Time Passwords there's an option with a drop-down menu called "OTP security level".

You can choose to use OTP for web access and regular password for email clients and other things that don't support OTP.


It will be good to have app-specific passwords, but this method is pretty secure IMHO.

photo
1

Unfortunately, it looks like an attacker with the regular password can disable OTP for web access, by initiating a password reset. With the regular password, they'll get the reset email (for example via IMAP), when they choose a new password, OTP is disabled.

photo
1

It would be better to get real "Device/App specific passwords" and real 2FA. But as I understand it's not easy for them to realise (they are a small team and development needs resources/money).

photo
3

Yes, the main problem is our very high security level here. It would be very easy and mostly a no-brainer if we would use direct access to passwords in LDAP or a simple database. Other companies and people might do that -- we don't. People may believe that this looks supersecure -- but we know, how weak the protection of the password hash must be. We will not do this for marketing reasons, making people believing in bullshit and playing with their trust, fooling them about what's really going on the servers behind the scenes.

LDAP binds are very secure, because none of our systems has ACCESS to the password. But LDAP binds don't allow mutiple password attributes and you also don't have to select "which" password attribute should be used (to get something like app/service specific passwords that does not work on other services).

It would be easy to use multiple (app specific) attributes and the simple READ different attributes by every server. But then the password (hash) must be readable from our LDAP/database and all servers get access to it. This is what many people do (even if they have not implemented a multi-auth system).

As I said: Others might do that. Go there, believe in their security and believe, that this is much much much better. I don't have a problem with that, I can not make everybody happy, especially if they believe in marketing and not in technical reality and the deep, mostly hidden hard facts.

Implementing multiple passwords is on our roadmap, but the ways we have to go are much much much more complex, then normal. We first have to create an internal centralized single sign on solution, where afterwards all services can connect and approve internal access by tokens. For security reasons, also our internal systems are using credentials to get access to something. Our webmailsystem *must* have username/password to get access to the mail storage. (I've build hundreds and thousands of ISPs, normaly you use a readable standard-master-password, stored in the config of the webmailsystems. If somebody has the password, he can get access to all mailboxes from all users. That's how mostly everybody else outside there is doing it, even the "really big" ISPs. And then it's easy to implement different passwords, because the webmailsystem get's the webmail password from the user but must not have the real mail-password to do the forward connect to the mail backend -- it can use the master password.)

We have a many different internal services, every single instance here must be able to speak to the single sign on system here and to get/approve access by tokens. It would be very easy if it's just a webmail-frontend and just a mail-server. There would be just two instances if we would not authenticate every single service internally. Every API-call. Every management-glue-stuff. Every access in the user's setup page. And so on. But we do that.

Implementing a SSO could be done in days. But changing and implementing SSO in every single backend interface is a bunch of work. And the whole system is not ready to use until the last backend is able to authenticate.

Yes, we would/could be ready if we would not have done anything else in the last 9 month. But there's lots of work to do and my team did also many, many improvements behind the scenes to give mailbox.org a very stable, very scalable, very well structured backend infrastructure. Which is also very important for security. So we're started preparing everything for SSO, but we will start with SSO internally after everything was re-factured and moved to our new structure. We will complete that until end of year and new services are already prepared or alreasdy use something like internal-SSO. But it still needs time and we have made our decisions, what is really important and raises security for everybody. So I'm sorry, I have to ask for patience, we will keep on going doing everything in the right order.

But, yes: For sure we all have the same idea for app specific and service specific passwords. And we're working on it. For sure, I wanna have it, too. :-)

photo
1

Thx for the detailed answer and outlook for some future development. Will there also be the new tariffs you already mentioned in Nov. '19? Sadly you killed your roadmap within your website. But posting every now and then many infos about future development. So why not re-introduce the roadmap (when you're already talking about future stuff)?

Another point:

I cannot understand how you can see a super safe one password solution much better than app specific passwords?

Even if the servers are not super high secure I think it's better to have app specific passwords than a single one. As you say on your website one of the biggest problems is the user and it's devices. So it's better to give them some ways to secure their devices better than just with one password!

Can't believe that big providers like Google, Apple, Fastmail,... have kind of security flaws within their app-specific passwords. Especially Fastmail is a good and really skilled provider.

But you're already working on it. That's a good sign and really looking forward for app-specific passwords and other new stuff.

photo
photo
1

I second this issue. It should be possible to set different passwords for each protocol : https, imaps, smtps, etc ...

photo
2

I would love to have this feature :) I recently migrated from google and was sad to see that mailbox did not offer app passwords.

photo
1

The same issue is also discussed as part of the 2FA Forum thread. Maybe this can be merged into one proposition.

photo
3

I agree that app specific passwords would be an very useful feature.

In case a passwords gets leaked (for example through some bug in a mail client, mail fetcher, keychain app...), the concerned password can simply be deactivated and other apps/devices remain unconcerned.

This also would remove the hassle of updating the passwords on different devices each time the main password is modified.

photo
2

As mailbox.org don't have their own apps we should have the abillity to login to third party apps with a password different from the main password.

It would also be awesome to let the app only acces some of the account with that password e.g. only contacts.

When a third party service get both email and password it is not very good. Even if you have encrypted emails they can change your password and lock you out from your own account.

photo
1

Hi.


I'm with you and also would like to have app-specific passwords.

But as far as I understood it's not that easy to implement due to security reasons.

mailbox.org connects via LDAP bind and there you can only define "one" passwords. They don't connect via proxies or via SQL-Databases (security reasons).

If you can define/have several passwords within one user-account for LDAP bind it would be possible.

photo