Jump to content

at3n

Member
  • Content Count

    407
  • Joined

  • Last visited

1 Follower

About at3n

  • Rank
    Regular

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ok... So that's tefBAD_AUTH: "The key used to sign this account is not authorized to modify this account. (It could be authorized if the account had the same key set as the Regular Key.)" The wording of that is not fully clear to me, but it looks like the account that you think is the regular key is not actually set to be the regular key. If you enter the public address of your main account into Bithomp, it will display the public address of the regular key assigned to it (The "Regular key:" field in the Information panel). Does that match with the public address of the secret that you're using to sign the transaction? (To check this, go Bithomp Tools, Offline, and paste the secret key in, and it will show you the public address underneath.)
  2. "Missing/inapplicable prior transaction." is an error code from rippled, equivalent to terPRE_SEQ, which occurs when "The Sequence number of the current transaction is higher than the current sequence number of the account sending the transaction." Especially when building offline transactions, you need to manually input the next sequence number of the wallet which you are doing the transaction on (in this case, the wallet with the disabled master key). You can find the next sequence number easily by using the main Bithomp page to look at the details of the address. You must enter exactly this number in the "Next sequence" box on Bithomp when building the transaction.
  3. Send it back once you have enough to justify the fee
  4. tefMASTER_DISABLED means that you're trying to sign the transaction with the master key, which is not allowed as it is disabled. You need to combine the public wallet address (r....) with the secret key of the wallet set as the regular key. So on Bithomp Tools, you choose Paper Wallet, then paste the regular key (s....), then tick "Sign on behalf of a different address", and paste the public address of the wallet which has the master key disabled. Then build the transaction that you need.
  5. Can you give an example of what you've tried so far?
  6. I agree that responsible entities operating within the cryptocurrency space should go to efforts to warn new and uninformed users about the dangers of transacting with crypto. I think that regulation will go a long way to helping in that regard, but such rules will never be able to make it impossible to send crypto to malicious or inaccessible destinations. I imagine that in the future there will be technological safeguards in place in certain products to attempt to save the typical end user from themselves. But we're a long way off from that being the default. But you must understand that the core concept of the system that you bought into (XRP and cryptocurrency in general) is fundamentally based on allowing users the freedom to do whatever they please with the currency, by giving them ultimate authority over their funds (in the form of their secret key). Without that freedom, it would not have the value and utility that it does. I think you're looking for the software developers who write the code, the server operators who willingly run that code, and the regular folk like you and me who freely choose to use the system, which is available for inspection at any time. It only works this way because people want it to.
  7. What do you mean "original"? The 24 words that you were given when you first created the account that you're now looking for, are the ones you need. If you've reset the Nano without keeping a record of those words then there is no way to retrieve them.
  8. Did you re-add the account to your Ledger Live? That may be necessary after resetting the Nano. (Accounts -> Add Account)
  9. https://gatehub.net/blog/gatehub-update-investigation-continues/ explained that user access tokens were stolen, and used to access the API. This bypasses 2FA. How the passwords were cracked is not so clear, but we know the hackers got the password hashes, so must assume that some very clever brute forcing was used for all the accounts that had strong passwords. Although we don't know if the self-confessed hackers are telling the truth, it is true that their story lines up very well with what Gatehub has released publicly.
  10. See https://xrpl.org/get-started-with-the-rippled-api.html#public-servers. Note that it mentions that they're not intended for business use. There have been several instances over the past years where other exchanges which have relied on the public Ripple servers experienced performance issues because the Ripple servers do sometimes have problems. So it's highly recommend to run your own.
  11. haveibeenpwned specifically links the email to Gatehub, and I'm inclined to trust that site more than random forum users. Yes, there are definitely people playing games, you definitely should not take everything as truth. But I do find it interesting to try to piece everything together.
  12. I'm intrigued by the post in your image that states the latest entry is December 2017, because 100% my email address found in haveibeenpwned was created after that date. Perhaps the database was stolen after 2017 but some records removed before the database was leaked; and perhaps there were undated email records that were left in? I would love to look through the database but I'm reluctant to get my hands dirty, as such.
  13. You absolutely certain that you tried all email addresses that you would have used? I'm now wondering if it was maybe not a 2017 database that was stolen, as having checked haveibeenpwned, it does not contain my email address from 2017 but does contain an email address that I used in 2018... I don't think that haveibeenpwned would have Gatehub passwords searchable, because the leaked database doesn't contain them in plaintext. Hope you re-keyed those funds in case they were just overlooked by the hackers? The layout of the database may not have made it obvious which keys were encrypted with the same password unless they wrote a script to check.
  14. I don't know how people on the cracking sites work, but I expect it's not just brute forcing. I recall that for the most part it was high-value wallets that were reported as being hit, so it makes sense that specific hashes were chosen and then people would work specifically to break them, rather than just running everything through a script. I assume that the crackers have access to other stolen databases, and even if people use unique passwords, a lot of the time they use different but similar passwords between sites, so perhaps a "human-assisted" brute force of limited scope is effective in some circumstances? Or social engineering tactics could have been used to help? I can't remember reading about when the database was actually stolen, does anyone know? They could have been working on the passwords for over a year potentially. All just speculation. I would also be interested if anyone had insight into how these cracking communities work. I don't think hashed secret keys existed. What was exploited was that the Gatehub API would send encrypted secret keys to an authenticated user. These could be decrypted with the account password. API usage I don't think would be visible to the user on the website, although Gatehub reported that it had its own logs of "suspicious" API calls. 2fa was bypassed by stealing the API access tokens, effectively allowing the attacker to act as if they were already logged on and not requiring further authentication. They probably wouldn't have used the web interface to do anything, it would have been scripted API calls.
  15. Gnosticplayers said that an online community dedicated to cracking hashes was used to break the Gatehub account password hashes. The password hashes were obtained from the stolen database. API authorisation tokens were also taken from the stolen database, which were used to retrieve encrypted secret keys from the API, until Gatehub invalidated the tokens. https://gatehub.net/blog/gatehub-update-investigation-continues/ The encrypted secret keys were decrypted using the cracked passwords. That's what I've gathered from the various information available; I'm not an authoritative source. It's also not clear who is telling the truth, but the above seems plausible.
×
×
  • Create New...