XTRABYTES unique network configuration has the added benefit of safeguarding against various network attacks. Listed below are several of the more common security concerns faced by online users today - and the security solutions we offer to thwart them.
A phishing type of attack is more a "hack" of the user than it is a "hack" of the system. In general, the best way to prevent this type of attack is through education.
At the XTRABYTES Academy, we aim to teach our users how to keep their data secure and to avoid becoming a phishing victim. As an organization, we also keep all ecosystem parts updated with the latest security patches.
The diversity of our system also contributes to its security, as each XCITE and STATIC node will be unique. Since each user will be using different xdapps/modules, no "global" attack strategy can succeed.
One of our strongest security solutions will be the use of a decentralized watchdog among the STATIC-side components of our network. This watchdog will filter out bad actors and out of date (insecure) peers. Additionally, we will be using temporary, short-term certificates to help ward off other types of attacks. If the case arises where a certificate gets stolen, the certificate will become unusable due to its short-term validity.
The risk of password leaking or the breaking of a weak password is extremely low (nearly non-existent). While XCITE uses a password (along with AES256 encryption of account data), passwords will never be used to gain access to the network communication. Consequently, passwords will never be sent or broadcast over the network, nor will we store any user passwords on the network.
Given the way our network is set up, private information will remain private. Since we separate how data is stored and validated, the validity of the data can be verified without the need for the actual data to be visible.
Network Security Solutions
The use of multi-factor authentication will also help detect bad faith network access attempts.
Our network even allows for the development of alert xdapps so that XCITE can provide immediate warnings of well-known attacks. So even if a single attack were to partly succeed, that attack would not be repeatable - since all other XCITE users will be warned via our decentralized attack database.
While users will be able to tailor their own user-interfaces and xdapps, non-technical users will be guided through the use of the network and xdapps by means of pop-ups and warnings.
Furthermore, we isolate the xdapps in the protocol level. If one component is attacked then all other components will remain secure.
Still, continuous learning is always the strongest prevention against phishing. That is why we encourage all our users to join the Academy and become as knowledgeable about security as possible.
Our Academy also supports our secure internal development process. Consequently, if a developer is uncertified then the developed product (xdapp) will automatically remain inaccessible to users.
To join our academy: http://academy.xtrabytes.global
A DDOS-Type Attack
A DDOS type-attack is an attack that works best on centralized systems. DDOS-ing a decentralized network is impossible if the network is large and decentralized enough.
The tiered setup of our network makes any external attack against the inner, more critical, components of our network nearly impossible.
The protected inner levels (L1 STATICS for example) are not accessible to non-members. Moreover, even L1 STATIC members must follow our connection and communication protocols. Any deviation from these network and communication protocols will be noticed by our decentralized watchdog and will result in severe consequences for the entity.
Recall that DDOS and flooding attacks rely on one or a limited number of points that are can be attacked. We’re able to avoid such attacks by using a decentralized network, one that is combined with access verification. In other words, while DDOSsing a single server is achievable, DDOSsing several thousand nodes simultaneously is exponentially much harder. This is especially true if you don't even know where all of them are situated in the network.
SQL Injection-Type Attacks
SQL injection type attacks are used in networks where passwords and certificates are stored in a centralized database. However, we don't use SQL databases for storing our data. Since our certificates will be managed in a decentralized manner, no central authority or database exists for the bad actor to maliciously inject data.
Data Validation Checks
Our basic rule is not to trust data without first checking its validity. So while someone might intentionally (or unintentionally) add bad data to our decentralized key-value storage, users can always check the signature/integrity/validity/consistency of that data before using it. As with other security solutions, PoSign will play a major role in this capacity.
Accordingly, we recommend that developers include data validity/integrity/consistency checks by default in their applications before using any data received over the network.
This is in stark contrast to centralized databases in which users must assume all data to be trustworthy. This is the key difference between our data storage solution and current security solutions.
Finally, it is important to note that our network will employ its very own decentralized network communication protocol. Since this is a non-standard DCN-protocol where increased isolation is used, it is far more scalable than the classic DCN-protocols.
Note also that all communication will be encrypted and signed by default. Furthermore, all communication within the network is peer to peer, so there is never a need to broadcast anything to the entire network
The term ‘reversible transaction’ does not refer to undoing a transaction or removing a transaction from the ledger. Instead, it refers to adding attributes to a transaction request under very strict consensus rules. This enables the issuer of the transaction request to reclaim or alter an existing transaction request. It does not involve any centralized authority making any decision on an existing finalized transaction.
In brief, our new chain technology will encompass at least two steps: a transaction request in which the initiator creates a transaction and posts it on the network. And a transaction that has been accepted or rejected by the recipient of the transaction. Both actions (request & acceptance/rejection) are separate entries on the blockchain.
Thus, reversing a transaction can be made once the initiator posts the transaction request to the network but before the recipient accepts or rejects the transaction. Additional attributes can be added to the transaction request, thus making it possible for the initiator to either reclaim or alter his request in a separate action (which will also be recorded on the blockchain). However, once a transaction has been finalized (either accepted or rejected by the recipient) it cannot be undone.
With all the recent news about online scams lately, wouldn't it be wise to become more proficient in online security? The XTRABYTES Academy offers a free Advanced Security course for those interested in protecting themselves from such scams. Academy students who take the course will be able to answer the following questions:
"How are 51% attacks conducted?"
"How do crypto-jacking attacks work?"
"What are DDoS and DoS attacks?"
"How do you protect yourself against phishing attacks?"
"How do ponzi and pyramid schemes work?"
"What are Coinjoins and Coinmixing?"
"How do Sybil and Eclipse attacks work?"
"How do keylogging attacks work?"
"What are dusting attacks?"
"What is selfish mining?"
"What protection exists against ransomware attacks?"
"What are Replay Attacks?"
Take our Academy security courses and learn how to protect yourself from such attacks!