Security Options: time delays, spending limits, and Safecoin security levels

Edit: @digipl made a good point about multilevel security for Safecoin this post has been edited to reflect this idea.

A few thoughts on how to protect an account after it is compromised.

*all time delays would be optionally set by the user
For example 24 hours, 48 hours, 1 week ect

*all actions effected by the time delay would not take place until after the allotted time period

*all pending actions within the time delay period can be canceled instantly

Possible Settings Effected by Time Delay
Password changes
Safecoin transfers
Safecoin security levels
Time delay settings

Safecoins could be dived up into multiple security levels. For example, one level could have no restrictions and be used regular daily transactions. A second level could be used for long term storage and transfers could be set on a time delay for added security. This time delay could be set to any amount. For example if the user sets it to 48 hours the requested Safecoins to be transfered would be put into a pending status and would not transfer for 48 hours.

Example:

Daily: 1,000 SC *No transaction restriction
Long: 567,000 SC *48 Hour time delay transfer restriction

All pending actions could be setup to be displayed when the user logs in to their account. This would alert the user of any suspicious activities. This would also give user time to react to any suspicious activity, allowing them to cancel unwanted activity and reset their security credentials.

4 Likes

That’s why many claim (I think it’s justified) that the slow(er) transaction of Bitcoin vs. Litecoin and others is a good thing.
Of course this doesn’t help with individual accounts (too short a delay), but with the security of the entire network in case of zero day exploits and such.

Well how would you pay (or how would apps work with this kind of account) when something is supposed to happen quickly or - if moolah doesn’t arrive within X hours - the app cancels your order?
In bitcoin payments that’s quite common, because if you don’t pay within couple of hours, you probably never will.
And if all orders are kept for days, one could end up with millions of fake orders and spend ridiculous amounts of resources re-checking their status.

A simple solution is have an offline account and don’t fund your online account with more SAFE than you can lose.

2 Likes

Good ideas! Having this stuff user configurable would be excellent for providing additional security.

I think this is a good idea, something I had discussed with @DavidMtl I think.

@betterthantrav

Good thinking to add time delays & spending limits. But there are a few problems with this problem.

First, you can delay a tx by 24 hours, but after 24 hours an attacker will try again. So it will become a back and forth game between you and the attacker, with maybe no end, since they have compromised your account.

Second, since you can “mint SAFEcoin” unless the delay mechanism works for this also, maybe the attacker could just mint the SAFEcoins and just import it and spend it on another account.

Maybe having the “Something that you know & something that you have/are” is the best way to protect an account, with a multisig option as master password. A 2 out of 3 scheme would work well, if you lost your phone, the 2 people that you trust could, recreate your account for you.

:stuck_out_tongue:

Not to sound to sophisticated, but now adays attackers use botnets. Maybe a botnet would be able to send the funds after 24 hours, while your asleep dreaming about your SAFEcoins.

According to the paper, the safecoin have multisign option. Maybe the wallet must have the possibility to separate safecoin in different level of security. A few spendable directly and others with the multisign option.

And the only “Something that you know” entry is, and by far, the security hole in the SAFE network. Find a solution to this is imperative.

1 Like

The time delay would allow the user to login and cancel any malicious transactions made by the botnet. The user then would be afforded time to reset his security credentials.

I agree with you that something the use has/is are important options for security credentials. But it’s also important to give the user as many options as possible.

Kinda like a bank account with checking and savings accounts. The checking account can be freely spent but the savings account has more security options.

1 Like

Good point. I think the 2 out of 3 scheme you suggested would help solve this problem to restet the users credentials when the account is compromised. I was also thinking a second secret backup password could be used to reset the user security credentials.

That is what daily spending limits are for, so the user can make basic transactions. If the user wants to spend more they will have to wait the pre-chosen amount of time before the account will release the funds.

@digipl brought up a good point about separating Safecoins in to two different levels of security. One level could be used for daily purchases and the other for long term storage.

Example:

Daily: 1,000 SC
Long: 567,000SC

In order for the user to transfer from long to daily they would have to wait the per-chosen amount of time. Multi sigs could also be thrown into this mix.

I’m curious to hear @nicklambert and @DavidMtl thoughts on multilevel Safecoin security?

1 Like

Because of @digipl really good point about multilevel Safecoin security, I edited my first post to reflect this idea.

Fine, so if your account has been compromised, the “other owner” can un-set the limit. What then?
Are you saying there should be a another time limit on setting the time limit?
Or that it is possible that an account gets compromised, but the rest of it (whatever that may be) remains intact? How would that 2nd tier of defense be protected? By another pass phrase?

Second, for petty cash uhm, safecoin, purchases, those are usually the ones that you want to spend instantly and not wait for hours till you can access some Safenet Web site.

Why would the thief wait till you reset the credentials (or PIN code or whatever) when he can do it himself?

I think eventually you’ll start liking the idea of having 2 separate wallets that I proposed earlier.

That is exactly what I am saying. All security settings could be time delayed until the user has the chance to use something like a multi-person trust or some other technique to reset their compromised security credentials.

The thief would not have the ability to reset the security credentials without waiting the specified time delay. By then the pending request to change security credentials could be canceled by the user. This could go on in a infinite loop until someone gives up. To break this loop permission could be given to a second account or multiple accounts, allowing them to reset security credentials instantly.

If the user is using the majority their Safecoins as a store of value then the user could have the option to split their Safecoions in to multiple security levels, one for instant transactions and the other for a long term store of value.

I like the idea of having multiple accounts/wallets. If I were to store any significant amount of value in Safecoin I would dive that value into multiple accounts/wallets adding as much security to each account as possible. Those accounts could then be used to unlock any account that may become compromised. As long as a majority of these account do not get compromised the accounts as a whole are safe.

Sorry ahead of time if this sounds rude, but I thought one of the main points of Safecoin was that a person could store value on the SAFE Network instead of stashing cash under their mattress or locking up gold in their basement. I believe that this is one of the major features that makes Safecoin better than Bitcoin.

Roger that, but if you have the 2nd account that’s almost as complicated as having 2 separate accounts (savings and petty cash, so to speak) without any special features.

No problem, you’re polite and we’re just freely discussing ideas.
My main point whenever anything comes up is to stick to the basics and get the first basic functionality out in testnet3 and so on. If the idea sounds appealing to the devs, great, but even then I’d prefer to see fancy stuff much later (that is, after v1.0 will have been released).

I completely agree, these are more like version 2.0 ideas.

1 Like

The more difficult the process the more security is added to the equation. Security can be broken down into a triad.

The more complicated the solution the less availability offered to the user, causing confidentiality and integrity to increase. It is a delicate balance, but it should be up to the user to determine their priorities.

1 Like

What we discussed was how to protect your wallet against a malicious app that would generate PUT request to drain your wallet. One of the idea was to have a spending pool and a reserve pool. App would only be able to spend Safecoins in the spending pool. We could also have spending pool specific for each app. This way you could assign a certain amount of Safecoin to try a specific app while giving more resources to app you trust.

Though, these doesn’t address the problem when your account is compromised. For that, I like the idea of having a root account with a delay mechanism that you only use to administer your other user account. If the root becomes compromised maybe we could reset it using a list of trusted friendly account as the trusted authority. I know @dirvine was suggesting a system like that for password recovery.

3 Likes

Unable to join the discussion, i can provide a useful case study to help thrash this important issue out:

1 Like

Unable to join the discussion, i can provide a useful case study to help thrash this important issue out:

1 Like

Sounds to me the weakest link in his security was humans. Social engineering is a powerful tool.

I like this part.

BTC-e had put a 48-hour hold on the account after a password change,
giving him time to prove his identity and recover the account.

and this

Most importantly, resetting a password is still easy, as Eve discovered
over and over again. When a service finally stopped her, it wasn’t an
elaborate algorithm or a fancy biometric. Instead, one service was
willing to make customers wait 48 hours before authorizing a new
password. On a technical level, it’s a simple fix, but a costly one.
Companies are continuously balancing the small risk of compromise
against the broad benefits of convenience. A few people may lose control
of their account, but millions of others are able to keep using the
service without a hitch. In the fight between security and convenience,
security is simply outgunned.

1 Like