Tag Info

New answers tagged

0

As @geekamongus points out, there are risks associated with any communication method so direct comparisons are pretty hard. However, there are several risks that cause me to not send sensitive communications via email. As the OP mentioned, there are problems with man-in-the-middle attacks at various stages of communication. An encrypted connection can help ...


1

In the asymmetric encryption scheme you can achieve two things: message confidentiality : this is done by using someone's public key to encrypt a message. Only the owner of the private key can decrypt the message message authentication : this is done by using your own private key to sign a message. Anyone with the public key can verify the signature of the ...


4

They don't need your public key at all to decrypt. You need their public key to encrypt the message, which they decrypt with their private key. The only thing they need your public key for is to verify that the message comes from you. In that sense it doesn't make sense to attach your public key, unless, for instance, you plan to confirm fingerprints over ...


1

The public key can be used to send an email securely to the holder of the corresponding private key, however the holder of the public key cannot ascertain that the message actually comes from you. Attaching your public key in the email though can problematic because he cannot verify that the public key attached actually belongs to you. If all he cares about ...


4

What you are looking for is theoretically viable, provided that you add the missing extra piece, i.e. some form of time stamping. However, behaviour of existing, deployed implementations is likely to be a problem. The conceptual idea is that if you verify a signature at date T on some message, then, at a later date T', you can still remember that the ...


8

The piece you're missing is that with these services (at least in my experience) you are required to create a login credential to access the secure service mail box the first time you use that particular service for that particular sender. Further, the sender (who contracted with the service) can set time limits for the items so that they become ...


0

In addition to rate limiting, you can make your email infrastructure report back to your app whether the email was accepted by the destination server or not; and rate-limit only if the emails are getting delivered successfully. A nice advantage of this method is that your app can tell the user whether the email they sent actually got through and is waiting ...


3

At work, I've implemented a very rudimentar and basic system to a contact form. Each IP is only allowed to send 5-9 emails a day (random number generated by IP). You can adapt this and add some options to (for example), allow only 1 or 2 per day in case the user asks it in a somewhat constant manner. Or block at all and only allow to resend if a specific ...


5

Add a time stamp to the email field, if an email has been resent in the last x minutes do not send another email. I would not use a captcha as bots are better at solving those than humans are anyway.


8

Rate-limit on a per-user or per-email-address basis. Since re-sending confirmation emails is rare, setting the limit absurdly low (say, two re-sends per day) should be sufficient to keep from flooding a user.


0

You could also do this: For every html page that is embedded in a mail, you download the img onto your server for display purposes, rewrite every link to point to your cache, remove javascript that resides on that page. Though this might not be a good idea, load/money/storage/bandwidth wise. This works very well on mails that are sent to you, but have some ...


4

Google spends a lot of money each year in bug bounty to ensure that Gmail isn't susceptible to XSS. Part of this effort has produced Google-Caja, which is an open source project that filters HTML to a "safe" subset. HTML filter sandboxes like Caja rely upon an "older" solution that uses complex parsing techniques, and thousands of regular expressions to ...


2

The problem is that not all spam is meant to exploit anything. Spam can simply advertise or be a part of a phishing attempt (which isn't an exploit). The thing to see here is that the URLs attempt to hide where they go and what they do. THAT is the thing that determines the fact they they are trouble. If you wanted an automated way to deal with these URLs, ...


2

No, they are not invalid URLs and the URL themselves are not exploits. If they point to exploit files it's hard to tell. They are obfuscated URLs intended to avoid spam filters. If you try to ping, for example, 0x5B.15251742, you will see that the address is translated to 91.232.185.30. The rest of the URL is a hash, and probably there are a few files with ...


1

I didn't know exactly how to make my point to management I know this sounds like a non-answer, but: It has been said that Management (the business) understand two things: money and risk. There is a cost of complying with PCI DSS (change/implementation costs, plus ongoing costs) There are risks associated with non-compliance (risk of fines, cost of ...


-1

To be fair, the most secure method is to use an image of your email address as previously stated. The main downside to the this is that if users have images disabled, they won't see it. This can be counter-acted, however, by in the HTML img alt="" alt tag, placing your email as HTML encoded characters: e.g. ...


0

If trying to obfuscate an email, what kind of strategies could be used to ensure that a human reader can understand but a program would not? An alternate solution (which does not display the email on the page) is to use a contact form with some captcha mechanism to prevent mass mailing. You could add to this a an automatic reply from a real email ...


8

Hiding your email using javascript can only get you so far. There are two types of scraping engines that are used to collect data from a website. Classic: The classic scraper is simply doing a GET request on the url and then parsing the HTML that is returned from the server. Advantage: Has the advantage of quick data collection and higher throughput both ...


2

To a large extent, yes, you will lose your anonymity. Github (and anyone monitoring Github) will be able to connect your email address to your IP address. A key element of anonymity (or more technically, pseudonymity) is keeping your separate identities separate. Your Hushmail account accessed over Tor is one identity, while everything you do through ...


1

Yes. If you use an account on Tor and also use the same account not on Tor, your ownership of the account can be traced via the use not on Tor. If you link two accounts (e.g. by listing an email from Tor on a non-Tor account), someone could potentially find that link and then trace the non-Tor account. This is one of many reasons "use Tor" isn't enough to ...


2

One fairly fool proof idea would be to include the e-mail address in an image vs. text. I would imagine this method could be defeated by a program that can read text in images, but it would be much harder to defeat than plain text.


17

You've got multiple methods really, you should of course consider that such bots harvesting this content are essentially scraping whatever pages they come across and searching for patterns that look like email addresses. As you say, it's a bit of an arms race and there's nothing stopping the people developing such scrapers from implementing these methods ...


1

In Australia at least ( yes I know it's 4 am right now ) I am assuming that the provider of the merchant account is either cba , anz, or Westpac ( I have had experience in dealing with these companies ) and I am assuming that this credit card data is then being manually entered into a eftpos terminal. The contract with those banks at least is very very ...


4

Your developer is trying to mix three different process into one: password registration, email validation and robot detection. Unfortunately, that makes the whole setup less secure and less resilient than it should be. Email is clear text and, nowadays, it pretty much guarantee to live forever and be included into several indexes and often kept for a long ...


5

PCI-DSS is not enforced by any government; compliance is a requirement for handling credit card transactions in any way. Fines and exclusion from processing are two enforcement actions that can be taken. I'm not sure exactly who can definitively do what but the card brands, the acquiring banks, and the processors are the entities usually involved in ...


2

PTR records are a security issue in my opinion, and I'm surprised it's not called out in either the Security Considerations or Eratta. This is an opportunity for someone to submit such a security note regarding this.


0

This is probably an instance of a "low and slow" distributed brute force attack, which is the latest evolution of password-guessing attacks attempting to login and compromise internet-connected computers. The most publicized and studied instance of this that I know of is the Hail Mary Cloud botnet. It sounds like a particularly badly done attack of this ...


2

To ensure only the user has the key for his IMAP-Account, you can save the login credentials in your session symmetrically encrypted by a key, that is stored in a cookie. So the user can unlock the login credentials with his cookie, without that the webserver can't login. Of course you have to ensure that all occurrences of the credentials are overwritten ...


0

No, this is a user enumeration vulnerability. As an attacker if I can use your login or forgotten password page to narrow my list from 10000 targets to 1000 targets, I will. The best implementation to solve this I have seen is that both the sign up and the forgotten password forms are a multistep process (exactly the same back-end/process after the ...


3

Since the author mentions his product is like Roundcube or Squirelmail.. I know how Roundcube works. Well, Roundcube's webmail DOES NOT have it's own method for logging in users. What I mean is that there is no database which stores anything about the user. Roundcubes takes the credentials user provided and puts them straight in imap_open(). If it ...


0

ive been thinking about this for a bit due to the fact that you should never store user passwords in plaintext. so I have came up with a possible solution for you. When a user signs up for a new 'service' to their account (e.g. they add gmail or yahoo, etc. ) what you are going to have to do is: Ask the user for their site password again (and validate ...


5

An intuitive and simple solution is to make sure that an automated script (malicious script) cannot try to register with a list of e-mails in order to figure out which ones are registered. For example, use CAPTCHA challenge as part of registeration to make sure it is a human trying to register an account. In this way, even if few user e-mails are tried, a ...


6

If this is a concern (i.e. if the fact of a person's membership would be considered sensitive information), one solution is to process the registration normally from the user's perspective on the registration page, but send a different e-mail out that explains that an account already exists/gives details on resetting the existing account (or replacing it if ...


0

Why you do not store the mail server credentials as part of the web server session data. Once the user type his mail server username and password in you webmail client application. You keep this information in the web server/user session. However, this means every time the user login to the webmail he will need to authenticate his identity at least twice ...


2

It looks secure enough considering the details you commented about, but I think the best course of action would be to cut the user ID out of the callback and have the user login normally to proceed with authentication if they are not logged in already. The exposure is not too bad as is, so if it is a pain to redirect back to auth page after login then I ...


2

Since you want to change the user information, you presumably already have a db with (email, first name, last name) so I would add the token there too (plus an expiration time). If you would use it in a stateless way (eg. just to confirm subscription), that's an acceptable approach, but you should be using a HMAC rather than a hash of concatenated values.



Top 50 recent answers are included