New answers tagged

2

This is probably correct in a statistical sense. A legitimate e-mail will probably (but not certainly) go through several hops not only on the destination side (which are mostly always the same for a given recipient, so that number is not interesting) but also on the sending side, and these will be recorded in Received headers. A spam, however, while sent ...


1

The email is referring to a breach of the LinkedIn password database that happened back in 2012. This was one of several HUGE breaches that was discovered around the end of May 2016, all of which actually happened earlier. Although we knew about the LinkedIn breach a few years ago, we thought it was only a case of "some passwords were stolen". 6 million ...


0

If you use the same password for other websites it definitely leaves you vulnerable. I'm not sure if it's a phishing attempt, however if you've started to form a pattern for repetitive password use it may be the smartest move to change to something new.


1

This doesn't sound like a natural influx of customer. Something fishy is probably going on. I would guess that this is a bot. So why would a bot sign up for your newsletter? It is probably looking for bulletin boards or comment fields or anything where it can post spam. Since bots can be quite dumb, it doesn't understand that it is just a newsletter it is ...


1

The issue was with a mailing list unsubscription service unroll.me that i subscribed to a while back. from their documentation: Unroll.me unsubscribes you by following a sender's unsubscribe instructions 24 hours after you've unsubscribed. As a backup, we automatically trash all future emails you'll receive from that sender. This is to ensure that if the ...


1

Anyone can create new email accounts with "John1234", and those usernames are considered "public" so you have no control over that. What is more interesting is how the spammer got a hold of the distribution lists. I would highlight the "change password" advice and make sure that proper hygiene is being practiced.


7

If you have access to email sent from those domains, the headers will contain a wealth of information that will help you determine where they're hosted. The downside is that, unlike poking at their public MX records, you'll need to get actual email from someone there in order to get headers to examine. The Received header of is prepended to the message by ...


1

If you have your publick key on key servers you can only share fingerprint, a link for download your public key is good if you haven't key on key servers or even when you have on key servers because maybe not all people use same key servers. I use fingerprint and also I have a link to my public key on my blog. gpg --recv-key ...


0

Well, as you can read above you can use SMTPS and STARTTLS to harden security for SMTP servers while sending mails. MITM can be mitigated with DKIM. DomainKeys Identified Mail (DKIM) lets an organization take responsibility for a message that is in transit. The organization is a handler of the message, either as its originator or as an ...


3

Depends what you mean by "email service", since as a general rule you're using some client to access an email service, and clients have different capabilities and restrictions. For example, mobile clients (smartphones) usually provide some support for Mobile Device Management (MDM). While MDM doesn't often involve retrieving files from the device - it's ...


3

Writing a standard is easy. I thought about this very problem about ten years ago. It comes down to the human/cost factor. How do you convince a billion technologically illiterate people to update their software for no perceived benefit, and convince the thousands of developers across a smattering of platforms to implement this protocol, and millions of ...


48

It's not that hard, why isn't it standard for years? Because that would not have solved the problem that PGP is trying to solve. PGP is an end to end encryption, so if there is any way for the SMTP server to subvert the encryption, then the scheme fails. In the case of the scheme you proposed, suppose Alice (alice@charlie.com) wants to send a private ...


30

integrating PGP into SMTP. PGP is a container format for data (like mails but not restricted to mails), which adds encryption and/or signature to the data. SMTP is a transport protocol. You don't integrate container formats into transport protocols. This would be the same as saying that you should integrate Office (container for text, images...) with ...


3

Encryption is already in place during mail transit (STARTTLS in SMTP), but not sophisticated enough to protect against MITM. I believe PGP is more of an end-user experience between email clients, which is helpful if you don't have full trust of the servers involved. (PGP is sometimes susceptible to MITM to the less-than-careful user, however, like in SSH, ...


1

The headers can be spoofed as well. You need to check the Received: headers and see if there is any provider that you do not trust, then there might be a phishing attempt. Headers can be spoofed for legitimate purposes in some cases. Related to this particular amazon e-mail you might want to check: Is this "security update" from security-update@...


4

The header you show is not the original mail header but has spaces where they don't belong, has lost spaces where they belong, has added line breaks and is missing several Received Headers. But, even if one would have the original header it will be impossible to verify the real sender, because too much can be faked. Using the DKIM signature shown in the ...


3

I think it would be enough if you can actually restrict the Sign up process to specific domain(s) in the Application itself. Three very important security points I can think of are below You can actually have a list of allowed domains for signup and thoroughly check every signup email against this list. Also should verify the signed up email by ...


3

In short: You cannot simply set up a rogue Google or Reddit e-mail server, because DNS. E-mail clients and servers rely upon DNS in very much the same way most web browsers and websites do. When a node has a package that requires delivery to an address at domain.tld, that node will first query their DNS servers to retrieve the MX record for that domain. ...


0

Since the site is on the domain, it bears reason that the owner of said domain, or an administrator of said domain, will have FTP access that allows them to modify the site and paste the code-key into the webpage. In regards to the google.com or reddit.com options, you'd have to be able to modify the site (probably the www.google.com/index or www.reddit.com/...


0

This says it better than I can: the purpose of a GUID is to be globally unique, not to be unguessable. and GUIDs are designed for uniqueness, not for security. So if you're concerned that an attacker could validate an email address that is not theirs, then do not use a GUID. Since it is a simple thing to solve, instead generate a 128 bit token ...


0

There is little security risk in using the method you described for confirming an email address of new accounts, but that's because there is little security risk in general in an invalid email address getting validated. Even if you used a much easier to guess ID than GUIDs, not too much can go badly (from a security point of view) if someone pulls one over ...


0

I don't see anyway to reconcile these two RFCs There are two ways to reconcile them: Choose Security (RFC 7465) over Backwards Compatibility (RFC 3501) Choose Backwards Compatibility (RFC 3501) over Security (RFC 7465) I have seen that Google has turned off RC4 on its email servers and is requiring TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, but that'...


0

RFC 7525 provides recommendations on how to deal with TLS protocols and ciphers today, including: 4.1. General Guidelines ... o Implementations MUST NOT negotiate RC4 cipher suites. And it is applicable to IMAP too: 5. Applicability Statement ... o Email software and services that wish to protect IMAP, POP3, or SMTP traffic with TLS....


0

You are looking at it in the wrong way. One of the following scenarios is probably happened: The attacker gained your contact list and used their email to spam your contact list - In this case I suggest you look over apps/programs that are installed on the device you use for checking your email. Attacker has hacked your email account and stole your ...


0

method: security risks link by email: email account could have been hacked security questions: personal information can be online searched of gathered (if you have some knowledge of the target) recovery code: not really practical. People usually lost it or store it in their email addresses (which leads us to security risk ...


1

How come this is in the email? OpenVPN does not care about application layer, which means that it did not introduce such content to the email. This means that this content is either introduced by the sender or by the mail server. While you offer only a few information about the mail itself let me just guess: there is a hostname openvpn. there is some ...


1

This is an interesting topic. Unfortunately you have narrowed down the possibilities with your exclusions. Otherwise I would have recommended a second channel. Some sites on the Darknet have the same desires you have outlined in your question: Either they don't expect people to have an email account (anonymous email is not that easy) or they don't trust the ...


0

A simple solution. When the user requests a password reset give them a randomised salt on the following screen. Send them a randomised reset key by email, with a link to the reset page. Store both the salt, the key, the user and an expiry time in the database. On the reset page they need to copy and paste the randomised salt from the other page, otherwise ...


0

A possible solution: 1) User opens website SSL password reset page and clicks the reset button. 2) server passes user browser to password reset verification screen 3) server also sends a one-time verification string via e-mail to user. 4) user opens e-mail and gets verification string 5) user pastes verification string into website reset verification screen ...


1

I doubt there exists any solution that will satisfy all of your requirements. You want a different, more secure solution than the ones that big companies have spent millions on researching. It can’t trust email, it can’t use outside sources like SMS, it can’t rely on security questions, doesn’t use offline (print) security codes, must be usable by any ...


1

You can't build a secure password reset system without a trusted method of communication. If the provider can't be sure who is attempting to reset the password, they can't be sure that they are only resetting it for the legitimate owner of the account. Therefore most modern password reset functions are a balance between a certain level of trust and a ...


6

So how can I make a secure password reset system, without trusting the email provider? You could have a notion of "trusted devices" - i.e. once a valid login is completed, you set a long lived token for that device which is stored as a cookie, and also stored (hashed) server-side. When the password reset token is sent via email, simply require that the ...


0

Maybe a stupid idea but an idea anyway. When you register you are asked for a picture to use if the account is lost. This picture can be anything : something random, a nice sunset of the Grand Canyon or a family picture. The system generates a hash of this picture and stores it (the picture is not stored). If you lose your password you are asked to ...


4

The main options are: Email verification only - most sites do this. It's simple and essentially free, and secure enough for sites like forums, e-commerce, social networking. Most users accept that they need to trust their email provider. Security questions - the most common additional security mechanism. This could be questions like "What's the name of ...


2

Yes, but there is a difference. While "cute-kittens.gif.exe" can raise some eyebrows, since a GIF shouldn't be executable, I wouldn't say the same about .tar.gz files. To be more clear, .tar.gz should be considered as dangerous as .zip. In fact, since any compressed archive coming from a Unix-like system is usually .tar.gz, a .tar.gz file could have a ...


-1

Use a solution that will send the "reset password link" plus the rest of the email(containing the reset token/temporary password) converted to an IMAGE. The characters used to reset the password would be image, and they could be hosted on your server and destroyed after X minutes. There was a smtp provider that did this(i cant remember right now). If you ...


3

There will not be any silver bullet for this. Fact: If you don´t want to trust other service providers, and don´t want to provide a private independent solution based on some 2nd factor app or token, you will end up needing to ask the user to keep a secret with him and make sure he will understand that he needs to keep it safe. An example: Take a look at ...


2

You do not need to trust the email provider to achieve this. The following architecture can be used to create a secure enough password reset link. Database A table with the following columns. UserID (100 char) ReqID (128 char) Stime (timestamp) VHash (128 char) On request page On the request page accept the user name, and along with that use a JS ...


-3

Interesting question. After going through the already mentioned answers and comments, I feel you are seeking for something that is easy to implement technically and something that the user can also remember and mention which is not known to others/hackers. So, all these lead to one possibility : Ask for 3 physical marks of a person. Like, Mole in ...


3

This is phishing no doubt. I found a similar message on Google: http://niepodam.pl/wiadomosci/3455214 (Google cache) The destination of the link "> Click here to validate your account information " in that email was "http ://cbi-id2.com/", which obviously is not apple. Whois data places that server in Panama... The crooks have probably moved on to a ...


2

Short answer:If you actually have chrome in spanish yeah it probably prevented the attack (its google blacklist for sites) This seems to be the case of phishing so on the site they would ask you to log in with your Apple ID to "verify" your account, purchase or something like that. Three basic steps to prevent this in future: 1) always check the senders ...


4

If the link visible in the location bar of the browser is the same link you've clicked on then probably nothing dangerous happened. But, it might be that the link in the browser is different from the one you've clicked on and that there were redirections and reloads before you've actually reached the site blocked by Google Safebrowsing. In this case it ...



Top 50 recent answers are included