Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
101010.pl is one of the many independent Mastodon servers you can use to participate in the fediverse.
101010.pl czyli najstarszy polski serwer Mastodon. Posiadamy wpisy do 2048 znaków.

Administered by:

Server stats:

583
active users

101010.pl: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.4.0-alpha.4

#domainname

0 posts0 participants0 posts today
Replied in thread
Public *
Erik van Straten

@sophieschmieg @neilmadden

IMO we need to stop coming up with algorithms to securely store "derivatives" of typically weak passwords, as

IT WILL FAIL.

From akkadia.org/drepper/SHA-crypt.:
❝
In addition, the produced output for [...] MD5 has a short length which makes it possible to construct rainbow tables.
❞

Please correct me if I'm wrong, but even in 2025 suggesting that a rainbow table is feasible for (lets cut a few bits for MD5 weaknesses) random numbers of 120 bits in length is BS (in order to create FUD).

If I'm right about that, the least bad thing to do is:

1) Everyone should use a password manager (pwmgr) because people simply do not have the ability to come up with a sufficiently strong password that is *unique for each account*, let alone for multiple accounts (sometimes hundreds), to remember them absolutely error-free, and to recall which password was chosen for which account.

Note: IMO password *reuse* currently is the biggest threat. Entering a reused password on a fake (phishing) website may have devastating consequences, because (when a password is reused for multiple accounts) chances are that ALL those accounts are compromised. Note that the complexity and uniqueness of the password are IRELLEVANT. And, what KDF is used on the server, is IRRELEVANT as well.

2) Let the pwngr generate a (cryptographically) random password, as long and with as much entropy as allowed by the server.

3) Use a strong master password and NEVER forget it (typical beginner failure).

4) Make sure the database is backed up in more than one place, and make a backup after each modification.

5) Make sure that the device the password mamager is used on, *never* gets compromised.

6) Double check that https:// is used. Better, make sure to use a browser that blocks http:// connections and warns you (Safari on iOS/iPadOS now supports "Not Secure Connection Warning"). In all browsers such a setting is OFF by default: ENABLE IT!

7) On a mobile device: use "Autofill". The OS then transfers the domain name (shown in the browser's address bar) to the pwmgr. If a matching domain name is *not found* in the pw database, assume that you're on a (fake) phishing website! In that case: DO NOT ATTEMPT TO LOG IN by looking up credentials yourself. Reasons for 7, two examples:
----
fake: circle-ci·com
real: circleci.com
----
fake: lîdl.be
real: lidl.be
----

If people would follow this advice (which is not just mine), even MD5 for storing a one-way derivative of the password on the server would be fine.

HOWEVER: don't use MD5 - because "never use MD5 for whatever" is easier to remember than "don't use MD5 if preimage attacks are possible".

P.S. I'm not a cryptographer (although I'm quite interested in the matter).

#MD5#PasskeysStillSuck#PasswordManager
Public
Stéphane Bortzmeyer

"Apparently, attempting to make money from an attack that killed 15 people is okay, but registering a domain containing a hyphen is a step too far."

domainincite.com/30661-dead-te

Domain Incite - Domain Name Industry News, Analysis & Opinion · Dead terrorist domains for sale, just without the hyphens - Domain IncitePeople are trying to make a quick buck flogging domains matching the names of suspects in recent terrorist atrocities, but they're stopping short of including the hyphens. The 2024 Christmas-New Year period was marked by two vehicular terrorist incidents on either side of the Atlantic: the Christmas market attack in Magdeburg, Germany on December 20
#domainName#DNS
Public
The New Stack

With the British government planning to cede control of the Chagos Islands, the future of the popular .io domain is uncertain. Should the British Indian Ocean Territory cease to exist, will ICANN retire the .io domain? Learn what this could mean for tech companies using the .io extension and possible backup strategies in this article by Jack Wallen.

#Operations #DomainName

thenewstack.io/what-is-the-fut

The New Stack · What Is the Future of the .io Domain?As per the regulations, ICANN should discontinue the .io domain if the British Indian Ocean Territory ceases to exist. Or will it change its policy so that thousands of websites (including ours) won't lose their domain names?
Replied in thread
Public
Erik van Straten

W.r.t. password managers (pw mgrs):

1) Make sure that you *NEVER* forget your master password.

2) Make an *OFFLINE* backup of the (encrypted) pw database after each modification. For example, rotate between multiple USB storage media.

3) Use a pw mgr that can generate strong (random, long, unguessable) passwords. Use that functionality to generate a unique pw for each account.

LAST BUT NOT LEAST
4) At least on mobile devices, configure the OS and pw mgr to locate your credentials *automatically* based on the domain name of the website you're visiting (using "autofill", which lets the OS pass the domain name –as used by the browser– to the pw mgr).

EXAMPLE WHY
If you receive an email (with SPF, DKIM and DMARC all fine) from:

    whomever@circle-ci.com

that instructs you to revalidate your 2FA settings in, e.g.:

    https:⧸⧸circle-ci.com/revalidate

Then a properly configured pw mgr will not come up with ANYTHING - because the record is for (without the dash):

    https:⧸⧸circleci.com

The deja vu after the 2022 attack (github.blog/news-insights/comp), described in discuss.circleci.com/t/circlec, is still alive and kicking since March this year (see crt.sh/?q=circle-ci.com and virustotal.com/gui/domain/circ). The fake site even looks better than the original one (I don't know whether it is actually malicious, or will just warn users who attempt to log in).

NOTE: if your pw mgr does not find a matching record in the pw mgr database, do NOT manually locate the "circleci.com" record. If you do: do NOT autofill or copy/paste your credentials for https:⧸⧸circleci.com to https:⧸⧸circle-ci.com! Using those creds, the fake site may immediately log in to the authentic website AS YOU - pwning your account.

WHAT I'M USING
I'm using KeePassium on iOS and KeePassDX on Android; they work just fine (disclaimer: I'm not in any way related to their authors, and do no warrant their reliability).

@steelefortress

The GitHub Blog · Security alert: new phishing campaign targets GitHub usersOn September 16, GitHub Security learned that threat actors were targeting GitHub users with a phishing campaign by impersonating CircleCI to harvest user credentials and two-factor codes. While GitHub itself was not affected, the campaign has impacted many victim organizations.
#Passwords#PasswordManagers#PasswordManager
Public *
Erik van Straten

Overview of my noteworthy posts (as of 2024-03-07):

* My Myth series
——
Myth#3: DMARC prevents phishing
infosec.exchange/@ErikvanStrat
——
Myth#2: Ransomware myths
infosec.exchange/@ErikvanStrat
——
Myth#1: "Not my problem"
infosec.exchange/@ErikvanStrat
——
Myth#0: Authentication (factors)
infosec.exchange/@ErikvanStrat

* Android passkeys gone (latest)
——
2) My last public answer to @agl: infosec.exchange/@ErikvanStrat
——
1) Don't use Android passkeys! (rest in Dutch): security.nl/posting/831554/Don
——
0) Android passkeys unexpectedly deleted or useless after sync seclists.org/fulldisclosure/20

* Apple passkey log in without auth
infosec.exchange/@ErikvanStrat

* Awareness: check the domain name!
infosec.exchange/@ErikvanStrat

* Big Tech facilitates cybercrime
infosec.exchange/@ErikvanStrat

* TOTP does NOT improve security
infosec.exchange/@ErikvanStrat

* SMS 2FA acceptable?
infosec.exchange/@ErikvanStrat

Infosec ExchangeErik van Straten (@ErikvanStraten@infosec.exchange)Myth#3: DMARC prevents phishing A LinkedIn article [0] regarding DMARC, DKIM and SPF, written by Roger A. Grimes [1] is, IMO, an interesting read. However, I do not agree with Roger that DMARC is a succes (Note: Roger informed us about it on Mar 04, see [2]). Here's my advice: *DO* implement SPF, DKIM and DMARC - both on your sending and receiving mail servers (and consider SRS, see below). Implementing these measures (as a sender), IS important to prevent receiving mailservers (often operated by big tech) from blocking your mails. Also, it is considered BCP (Best Current Practice) to implement them on your recieving mail servers, and to honor the treatment of received mails as specified by the sender. However, w.r.t. recipients being able to distinguish between (phishing) emails SPOOFING your domain, versus emails ACTUALLY originating from your sending domain: keep your expectations at the level "FORGET IT". Details follow below, see also [3]. [0] https://www.linkedin.com/pulse/phishers-abusing-legitimate-neglected-domains-pass-dmarc-roger-grimes-wrl3e/ [1] @rogeragrimes [2] https://infosec.exchange/@rogeragrimes/112037240888788307 [3] "Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy" Authors: Enze Liu, Gautam Akiwate, Mattijs Jonker, Ariana Mirian, Grant Ho, Geoffrey M. Voelker, Stefan Savage https://arxiv.org/abs/2302.07287     ANTI-SPOOFING PROTOCOLS There are, and have been, a lot of (proposed) anti-email-abuse protocols, including SPF, micropayments [4], "Caller ID" [5][6], FairUCE [7], DomainKeys, DKIM, DMARC and ARC. [4] https://techmonitor.ai/technology/gates_backs_away_from_postage_stamps_idea_in_spam_vision [5] https://news.microsoft.com/2004/02/24/bill-gates-outlines-technology-vision-to-help-stop-spam/ [6] https://www.zdnet.com/article/anti-spam-firms-test-caller-id-for-email/ [7] https://www.crn.com/news/security/159904438/ibm-to-spam-spammers     NOT ANTISPAM Most, if not all, of these protocols were advertised as ANTI-SPAM MEASURES (by marketeers, including Bill Gates [5], who apparently failed to understand anything about them): they definitely ARE NOT THAT. In fact, many of the protocols mentioned are dead and burried, and the rest of them are, IMO, seriously ill. They are NOT antispam measures for multiple reasons, perhaps most inportantly because spammers *DO* buy their own (possibly look-a-like) domain names, and correctly set up SPF, DKIM and DMARC for those donains, and send mail from there. In fact, it may be even EASIER for spammers to set those things up than for decent domain owners, for example because the length (and nesting) of SPF records in DNS is limited. All protocols mentioned were, in fact, DESIGNED to prevent SPOOFING (forging, counterfeiting) of the sender domain (my prediction, in 2005, that SPF and FairUCE would NOT prevent spam, was spot on; see [8] - in Dutch). [8] (Dutch) https://www.security.nl/posting/10403/Waarom+SPF+en+FairUCE+op+termijn+geen+spam+bestrijden     ANTI-SPOOFING PROBLEMS Not only do the protocols mentioned not stop spam, they also, IMO unfortunately, too often, do not effectively prevent sender (domain) spoofing. Below I'll describe most of the (important, leaving out minor-) problems of SPF, DKIM and DMARC that I'm aware of.     PROBLEM #1: MUA'S AND PEOPLE An increasing number of people use MUAs (Mail User Agents, i.e. the program used by the recipient) that DO NOT show (display) the SMTP sender address (containing the sender domain) in received emails. This renders all of these measures pointless; if the recipient does not evualuate the sender domain name, ANYONE may have sent the email. Furthermore, PROVIDED THAT a MUA reveals the sender domain name, AND the recipient takes notice of it, AND the recipient knows how to interpret DNS domain names   (i.e.   accounts.google.com  differs from   accounts-google.com  (impersonator)   ), AND *magically* knows that a sender domain, such as "paypal.co.uk", ACTUALLY belongs to paypal.com - EVEN IF PayPal clearly states (on their website) that all legit mail from PayPal uses paypal.com as it's sender domain, ONLY THEN the recipient may be able to distinguish between legit and spoofed sender domains. IMO this is an EPIC FAIL, in particular because many organizations use multiple, different, sending domains (e.g. for conducting surveys). People are TOUGHT that domain names are unpredictable (i.e. that microsoftonline.com belongs to the same owners as microsoft.com, but not e.g. microsoft-sso[.]net [9]). [9]: see the IOC's at the bottom of https://www.group-ib.com/blog/0ktapus/     PROBLEM #2: SPF & FORWARDING A serious side effect of SPF is that it breaks forwarding (legitimate relaying) of emails. Note: when mentioning possible email addresses below, I use ".tld" i(nstead of the actual TLD, such as .gov or .com) For example, if a Fox News reporter "rep@foxnews.tld" mistakenly still (or wishfull thinkingly) sends an email to "trump@whitehouse.tld", and the Whitehouse's mail server forwards the mail to "trump@mar-el-lago.tld", then the Mar-el-Lago mail server's SPF implementation will typically block the mail while responding:   "The IP address of whitehouse.gov   is not permitted to send mail from   foxnews.com." The usual "SOLUTION" for this problem (called SRS = Sender Rewriting Scheme), is rather messy. Each potentially forwarding mail server, such as the whitehouse.gov's, will have to become STATEFUL. Effectively, for each to-be-forwarded email, the server must create a kind of email account (temporary and unique) with a name like "GUID_on_behalf_of_rep_at_foxnews@whitehouse.tld". This is necessary because a return path for error messages (such as mailbox full) must exist, as well as for other SMTP notifications (e.g. mail was read) generated at the Mar-el-Lago mail server. The whitehouse.gov mail server must also associate the temporary account name with the originating email address (in order for mails received by the "GUID..." account to be forwarded back to "rep@foxnews.tld"). IMPORTANT note: YOU are not in control of, potentially forwarding, receiving email servers. You may not know that they don't use SRS until you find out that your email was undeliverable.     PROBLEM #3: MAILLISTS AND DKIM Mailing list servers tend to modify emails in such a way that DKIM signature checks fail. For example, regularly "Cryptography list" emails, forwarded by the metzdowd.com mailserver, end up in my spambox with the subject line altered: "[DKIM] " is inserted at the beginning of that header line.     PROBLEM #4: DMARC: SPF *OR* DKIM The DMARC protocol is essential because, in contrast to SPF (and partially DKIM), it checks the domain name IN THE "FROM: " FIELD. That field is usually visible in MUA's,; note that SPF checks are based on the "envelope-from" domain name, which may be empty (in SMTP error messages, in order to prevent endless loops) and therefore is not fully reliable, and typically invisible in MUA's. In fact, in most (mobile) MUA's the user has no way to visualize email headers (even forwarding a probably scam-mail with headers is hard or impossible). Probably because of problems #2 and #3, DMARC is still happy if EITHER the SPF or the DKIM check (performed by the receiving mail server) fails - that is, AT LEAST ONE of the SPF and DKIM checks must succeed for the DMARC check to return a positive result.     PROBLEM #5: MS SAFE SENDERS Likely as a result of user complaints regarding not receiving mails because of DMARC failures, Microsoft USED to tell recipients to add legit senders to their list of "Safe senders". This, of course, was stupid. It meant fully bypassing SPF, DKIM and DMARC, by also delivering SPOOFED mails to the user's inbox. For example DocuSign advises customers to add docusign.com to their list of Safe Senders [10] - which used to make it easy for scammers to spoof their sender domain name. Apparenly Microsoft changed this behavior last summer: [11]. However, other recipient mail servers may still have such measures in place. [10] https://support.docusign.com/s/articles/Why-am-I-not-getting-DocuSign-email-notifications?language=en_US [11] https://techcommunity.microsoft.com/t5/exchange-team-blog/announcing-new-dmarc-policy-handling-defaults-for-enhanced-email/ba-p/3878883     PROBLEM #6: BEC Compromised sender email accounts, but also compromised "trusted third party bulk mail serviced" (example: [12]) are a big problem. [12] https://www.bleepingcomputer.com/news/security/hacked-sendgrid-accounts-used-in-phishing-attacks-to-steal-logins/     PROBLEM #7: VARIOUS OPINIONS In discussions between MTA admins regarding SPF, DKIM and DMARC, I notice significant differences in opinions which settings to use on sending MTAs (Mail Transfer Agents = mail servers) and on receiving MTA's, such as whether to use ~ or – for SPF on the sending server. Your mileage may vary... In the end, of course you are not only depending on the configuration of potentially FORWARDING mail servers, but, most importantly, on those of RECEIVING MTAs. There's not much you can do if a receiving provider (such as Microsoft) decides to (albeit conditionally) deliver mail with an SMTP sender address spoofing YOUR domain to inboxes of your recepients. In fact, admins of receiving MTAs may change settings at any time without notice (to senders AND recipients).     CONCLUSION Don't be tempted to believe that SPF, DKIM and DMARC, will prevent each recipient, in any case, to be able to distinguish between SPOOFED emails (seemingly sent by you) and emails that were REALLY sent by you. Any AUTHENTICATION check (verification of an identity) that DOES NOT effectively prevent IMPERSONATION, is hardly useful - if at all.     Edit 20240306 11:40 UTC: Changed title (old: "Myth#3: DMARC stops spoofing") and edited the first paragraph. #SPF #DKIM #DMARC #spoofing #phishing #dmarcBypass #Outlook #Microsoft #Microsoft365 #SMTP #fakeSender #forgedSender #forgedEmail #spoofedEmail #FairUCE #antiSpam #antiSpoofing #antiSpoof
#DMARC#ransomware#notMyProblem
Public
Keith Dawson

Finally I've gotten my new domain name, won at auction, out of the evil clutches of Network Solutions, Inc. and onto my own preferred provider. This is Dynadot, whom I recommend to all enthusiastically and wholeheartedly.

It has been a 2+ month journey. I won the auction on Oct. 27. That began a 60-day waiting period (per ICANN rules) before the name could be transferred to a different registrar. I started the transfer process on Dec. 28 and it has just now completed.

Part of the time elapsed was down to NSI's dark patterns. When I requested from them the authorization code that I needed to give to Dynadot to initiate a transfer, NSI couldn't simply show me the auth code on a web page — as all other registrars I have dealt with do. Oh no. They had to initiate a 3-day "review," with a human in the loop, to verify that I had in fact checked all two boxes correctly.

It's done now. Perhaps if / when the FTC's proposed new rules ( tinyurl.com/yae5s6sv ) go into effect, NSI won't be allowed to make it so difficult and time-consuming to get a divorce.

The White House · Biden-Harris Administration Announces Broad New Actions to Protect Consumers From Billions in Junk Fees | The White HouseNew proposals would crack down on junk fees across industries and ban fees for essential bank services Today, President Biden will be joined by Federal Trade Commission (FTC) Chair Lina Khan and Consumer Financial Protection Bureau (CFPB) Director Rohit Chopra as they announce new efforts to crack down on junk fees and bring down costs…
#DomainName#netsol#Dynadot
Continued thread
Public
Neo-Rodneyite ✍🏿📖

Now, a toss up!

Do you use this #DomainName more often than you use your e-mail address? Phone number?

It's a slightly unfair question because the latter two have more social utility whereas a domain name _can_ be made to have social utility but the upfront cost is (way) higher.

· 12 people · Closed
ExploreLive feeds
About