Liberty SMS - Unauthorized access to IT infrastructure

[SmartKit]

No. Password is not stored. It is salted and hashed and the hash is stored... on Liberty's side for the Liberty system and on the banks side for the banks system.

There is no way to store the password securely. You never store passwords.

Another one with nothing to say about the subject? Seriously people. Don't store passwords.

So what you're saying is that there is a way to store the password securely?

Or did you neglect to mention, during your generally patronising and insulting rant, was that there is no secure way to store a password that would allow for it to be viewed in plaintext?

 

[JerryMungo]

And please tell us how you are going to store this API key.
Also how a read only API key differs from a read only bank user account.

You don't have to ask people to divulge their passwords and change them in the event of a breach. You also guarantee read only access.
Here: https://docs.apigee.com/api-platform/security/oauth/oauth-introduction

The point is you never request someone to give you their credentials to third party sites. Why would you?

 

[whatwhat]

You don't have to ask people to divulge their passwords and change them in the event of a breach. You also guarantee read only access.
Here: https://docs.apigee.com/api-platform/security/oauth/oauth-introduction

The point is you never request someone to give you their credentials to third party sites.

But surely they can breach the API keys? What happens then?

I'm learning a lot here.

 

[JerryMungo]

But surely they can breach the API keys? What happens then?

I'm learning a lot here.

You as a client revoke the key on your banking site. At worst, someone has had a peep at your bank statements if you aren't quick enough.

It's how modern cross domain security works these days. Think facebook and third party apps

 

[JerryMungo]

Think of it as a second read only access password only valid from Liberty's servers but easier for you to manage. Each vendor that needs access has their own unique API key. If one is compromised, no need to revoke or reissue them all.

Liberty still has to store it securely but it's technically not a password to access your services globally and only valid from their servers.

 

[JerryMungo]

So what you're saying is that there is a way to store the password securely?

No, I'm saying that the password is not stored in any form. A hash is a derivative, it cannot be used to recover a secure password.

Or did you neglect to mention, during your generally patronising and insulting rant, was that there is no secure way to store a password that would allow for it to be viewed in plaintext?

Feel free to explain how you came to that conclusion.

There is no secure way to store a password that would allow for it to be viewed in plaintext?

Right. That's what I'm saying. I'm saying Liberty and others should not be storing your banking credentials or your credentials for any third party system on their system. They should also not (and probably are not) storing your password for their services on their own servers. Only the hash is stored - which is used during authentication. The hash is not the password - it's the result of a computation based on the password and other data. The password can't be derived from a secure hash.

 

[SmartKit]

Right. That's what I'm saying. I'm saying Liberty and others should not be storing your banking credentials or your credentials for any third party system on their system. They should also not (and probably are not) storing your password for their services on their own servers. Only the hash is stored - which is used during authentication. The hash is not the password - it's the result of a computation based on the password and other data. The password can't be derived from a secure hash.

But that's not really what you said... Ammiright?

 

[JerryMungo]

But that's not really what you said... Ammiright?

Feel free to use the quote feature if you disagree.

 

[SmartKit]

Feel free to use the quote feature if you disagree.

Except encryption is also a derivative, so that's not really what you said... again.

Oh sorry: https://mybroadband.co.za/vb/showth...astructure?p=21693357&viewfull=1#post21693357

 

[JerryMungo]

Except encryption is also a derivative, so that's not really what you said... again.

Oh sorry: https://mybroadband.co.za/vb/showth...astructure?p=21693357&viewfull=1#post21693357

Take a look at what you yourself quoted

"encrypting the password instead of hashing it is a bad idea and is borderline storing plain text passwords. The whole idea of slow hash functions is to thwart the exfiltration of the user database. Typically, an attacker that already has access to the database can be expected to also have access to the encryption key if the web application has access to it."

There's a big difference between storing a password in encrypted form and storing the digest.
You need to go back to the start of the convo to get what I was pointing out

If they need to log into the banking on someone's behalf, they need to be able to decrypt those passwords.