I'm using an open source Let's Encrypt tool, and it has worked for years on some servers. On one, in the US, the certificate is being found not valid because it is "not valid yet". The "Valid From" appears reasonable, perhaps a few hours off, but UTC would account for that.
I am suspecting that the problem is in the client validation, but welcome any thoughts on the specifics of why that might be so we can dig deeper.
Without more information I can't be certain, but the most likely cause is that the server's clock is off by a few hours. If you have control over this server, make sure that it is properly syncing with a networked time server. This is usually done through NTP.
For the record, it was the web server that was loading the certificate, that was not taking the time zone into account. Due to the offset from UTC, it was thinking the certificate hadn't started yet.
Related
Can anyone show me an example of a couple of screenshots using the klist command to show at least 3
cached tickets (any types) you have obtained from your own Domain Kerberos server.
I'm guessing this is an exam or homework question given the odd specificity. Please don't post these here without at least showing you've done some work that isn't just wasting everyone's time.
Klist is pretty trivial to use. By default it takes zero command line parameters and lists all the tickets in the cache. On a domain joined machine it'll usually have a couple in there already. Whenever you connect to a server and do Kerberos it'll cache a ticket. Therefore if you connect to a handful of servers, say, the domain controller itself using things like SMB or LDAP or whatever you'll get tickets in your cache. Go do that.
I was cruising around the browser reading articles about MItB and still can't find a technical way of getting rid of an MItB infection. hence, I was wondering: Is there is such a way to delete an MItB attack technically? If you were to click an infected link on a computer or mobile through a browser, in which triggered the MItB and infects your web browser, can you destroy the vulnerability by reinstalling the browser, whether in your phone or computer? More importantly, does MItB make any difference in computer and phones?
Man in the browser (mitb) is a nasty attack because "traditional" security mechanisms are not very effective against it. This is a classic example of a Trojan because the "enemy" is behind your city wall (security layers). Encryption won't help because the data the attacker is accessing is already decrypted. So the attacker has the chance to inject scripts, modify transactions, collect personal data, etc., without the user's knowledge. From the user's POV, everything is fine. They won't notice anything is wrong until the damage is done.
Your idea of reinstalling the browser is unlikely to work. The Trojan can survive the reinstall because it is not part of the browser itself. It is either an extension (or "browser helper object"), malicious JavaScript, or an external program which messes with the browser's API calls.
Also, active detection and mitigation by antivirus and other anti-malware software is not very successful. AV will detect some Trojans, but the detection rates are low. Trojans are, by design, engineered to avoid detection.
One approach you will often hear mentioned is 2-factor authentication or out-of-band transaction verification. The most common is to send a code to the user's phone or e-mail. In some systems, this code will also include information about the specific transaction which is being verified. The idea here is that the phone or other communication channel will not be impacted by the Trojan, so it should be safe from interference. But honestly I don't really think this is 100% safe. You will still have users who ignore any warning signs in the message and just blindly continue typing in the verification code into their browser because they are 1) ignorant 2) in a hurry, or both. And even then, you are assuming the the out-of-band communication mechanism has not been compromised. That's a big assumption. If you're wrong, then it will be completely ineffective.
Another approach is to sidestep the problem and look at the user's behavior from the server side. If you can establish a model of their "normal" behavior, then there is a reasonable chance of identifying suspicious activity. What is suspicious activity? It can be anything like a sudden increase in large transactions, changing IP address in the middle of a session, and navigating between pages in an "unnatural" way. When this type of behavior is detected, you can notify the user or take steps like locking their account or just rejecting a transaction. Of course, this will be limited to a specific service (e.g. the user's bank) and there is always a chance of false positives. It doesn't address the root of the problem, because the user's platform will still be infected.
The defense right now is not detection but prevention. Stop the Trojan from getting in. The most obvious one. Don't download and open or execute anything unless you trust the source 100%. That means the source should have E2E encryption and a trustworthy SSL (TLS) cert, preferably extended validation (EV).
Also make sure your OS is up to date with the latest security patches. Finally, don't use browsers with known vulnerabilities. And even then, avoid suspicious browser plugins/extensions.
I am writing a WP7 app and would like to include features to share highscore data using Amazon's AWS as storage service.
As far as I understand WP7 XAP files are (currently) safely encrypted and no known jailbreak for the phone exists. However, given that such a 'safe' encryption can be temporary, I would like to understand if/how this violates best practice.
AWS' dynamoDB uses temporary access tokens that can be generated using given account data and are valid for 36 hours the tokens must be verified using a signature with any request.
I am considering that all access data will be stored in the XAP file, which will also generate the temporary access token and signature. The information will be passed via https requests between the phone and AWS.
I was trying to work out alternative processes including passing the generation of the temporary token calculation to an external webservice, however I cannot think of a way to protect this data which would not be similarly compromised if the XAP file was accessible.
Am I missing the best practice approach completely or am I just overly cautious?
Thanks.
You won't ever be able to prevent users from sending false scores, pretty much for the same reason as unofficial cheating apps exist for every popular game. The best you can do is making it harder.
With a simple approach, the client sends the score directly to the server, without any kind of encryption. Someone can cheat just by running the app on the emulator and capturing the outgoing packets, then opening the same URL on his desktop browser. Estimated time: less than 10 minutes, and it can be done by anyone who knows that he can download XAPs directly from the marketplace, remove the manifest, and deploy it on the emulator.
Then you can add an encryption key on the client. Now someone has to know C# and Reflector to extract it, but it's still easy for someone having those skills.
Next level, you can add an encryption key AND obfuscate the assembly. Knowledge of CIL and Relector are required to extract the key. It'll take 30 minutes to an hour to a highly skilled developper to extract the key, and many hours for most developpers.
Finally, you can add multiple steps to confuse even more the intruder (for instance, downloading a temporary token from a server and using it somehow in the score sending process). Also, you can design the scoring system in a way that some scores are illegal (dumb example: if the minimal scoring action earns 2 points, then if someone sends an odd number as a score you know he's cheating. This one is easy to figure out, but you can make much more complex rules).
In any way, keep in mind that your system will always be vulnerable, it's only a matter of how much time it will take to the attacker to break through it. If it takes many hours or days to a highly skilled developer, then unless you're offering some worthy prize to the best player, you can safely assume that nobody will bother doing that.
My web server is in east coast.
I sent an email from my web server at 1PM PST time which is 4PM Eastern time.
I am resided in west coast and when I see the page, it shows 4PM which is future time for me.
How can I see 1PM, someone in east coast 4PM and so on?
The date is stored in MongoDB which is UTC. I also convert date before displaying:
#Model.DateSent.ToLocalTime().ToString();
This is how I set the time when mail is sent:
DateTime.UtcNow <-- So I am storing date in UTC already
Thanks
There are two parts to your question. The first is the mechanics of localizing a dateTime in C#. Since I'm not a Windows guy, I'll leave that to either someone else to answer or you to look up in the docs, but I'm willing to bet that ToLocalTime() has a friend that takes a TimeZone or a Locale.
The second part, which is more interesting, and something I've had to deal with a few times in the past is how to know what timezone to use. There's no right answer, but there are a few strategies:
The simplest, and perhaps the best, if there's a concept in your system of a user account
is to simply make the Locale a user preference.
If there's no concept of a user account one's always logged into there are a few ways
to go
you could make it a choice that is saved in the session, but that's a bit annoying
to force them to select every time
a better alternative might to be geocode the inbound IP address and set it from
that. There are geocoding apps, databases and services. Most cost, but I know
MaxMind has a free edition that does ok. That will mostly work. The catch is
users coming via some large private network. I live near Philadelphia. My home
network usually geocodes pretty well, though a few services place me in Delaware,
where my ISP is located. But at work, where the whole company goes out through
a single web proxy, I look like I'm in North Dakota.
more reliable, but perhaps more involved, is to grab the browser's timezone
using getTimezoneOffset() in Javascript and push the answer up to the server.
I suppose the other option might be to convert the time locally in the browser,
where the timezone is freely availiable, but that implies that the data is
coming down via AJax or similar and then being updated via JavaScript. Fine if
you're doing a app that is fundimentally Ajax RIA based, just send the data
in UTC or as a time_t. But kind of silly and annoying for a classic web app
that isn't already processing all the data client side.
My first choice would be a user preference. If that's not an option I'd probaly push the timezone from the client. And if that's too involved, go for IP geolocation.
As many of you probably know, online banks nowadays have a security system whereby you are asked some personal questions before you even enter your password. Once you have answered them, you can choose for the bank to "remember this computer" so that in the future you can login by only entering your password.
How does the "remember this computer" part work? I know it cannot be cookies, because the feature still works despite the fact that I clear all of my cookies. I thought it might be by IP address, but my friend with a dynamic IP claims it works for him, too (but maybe he's wrong). He thought it was MAC address or something, but I strongly doubt that! So, is there a concept of https-only cookies that I don't clear?
Finally, the programming part of the question: how can I do something similar myself in, say, PHP?
In fact they most probably use cookies. An alternative for them would be to use "flash cookies" (officially called "Local Shared Objects"). They are similar to cookies in that they are tied to a website and have an upper size limit, but they are maintained by the flash player, so they are invisible to any browser tools.
To clear them (and test this theory), you can use the instructions provided by Adobe. An other nifty (or maybe worrying, depending on your viewpoint) feature is that the LSO storage is shared by all browsers, so using LSO you can identify users even if they switched browser (as long as they are logged in as the same user).
The particular bank I was interested in is Bank of America.
I have confirmed that if I only clear my cookies or my LSOs, the site does not require me to re-enter info. If, however, I clear both, I had to go through additional authentication. Thus, that appears to be the answer in my particular case!
But thank you all for the heads-up regarding other banks, and possibilities such as including the User-Agent string.
This kind of session tracking is very likely to be done using a combination of a cookie with a unique id identifying your current session, and the website pairing that id with the last IP address you used to connect to their server. That way, if the IP changes, but you still have the cookie, you're identified and logged in, and if the cookie is absent but you have the same IP address as the one save on the server, then they set your cookie to the id paired with that IP.
Really, it's that second possibility that is tricky to get right. If the cookie is missing, and you only have your IP address to show for identification, it's quite unsafe to log someone in just based of that. So servers probably store additional info about you, LSO seem like a good choice, geo IP too, but User Agent, not so much because they don't really say anything about you, every body using the same version of the same browser as you has the same.
As an aside, it has been mentioned above that it could work with MAC adresses. I strongly disagree! Your MAC address never reaches your bank's server, as they are only used to identify sides of an Ethernet connection, and to connect to your bank you make a bunch of Ethernet connections: from your computer to your home router, or your ISP, then from there to the first internet router you go through, then to the second, etc... and each time a new connection is made, each machine on each side provide their very own MAC addresses. So your MAC address can only be known to the machines directly connected to you through a switch or hub, because anything else that routes your packets will replace your MAC with their own. Only the IP address stays the same all the way.
If MAC addresses did go all the way, it would be a privacy nightmare, as all MAC addresses are unique to a single device, hence to a single person.
This is a slightly simplified explanation because it's not the point of the question, but it seemed useful to clear what looked like a misunderstanding.
It is possible for flash files to store a small amount of data on your computer. It's also possible that the bank uses that approach to "remember" your computer, but it's risky to rely on users having (and not having disabled) flash.
My bank's site makes me re-authenticate every time a new version of Firefox is out, so there's definitely a user-agent string component in some.
It could be a combination of cookies, and ip address logging.
Edit: I have just checked my bank and cleared the cookies. Now I have to re-enter all of my info.
I think it depends on the bank. My bank does use a cookie since I lose it when I wipe cookies.
Are you using a laptop? Does it remember you, after you delete your cookies, if you access from a different WiFi network? If so, IP/physical location mapping is highly unlikely.
Based on all these posts, the conclusions that I'm reaching are (1) it depends on the bank and (2) there's probably more than one piece of data that's involved, but see (1).
MAC address is possible.
IP to physical location mapping is also a possibility.
User agents and other HTTP headers are quiet unique to each of the machines too.
I'm thinking about those websites that prevents you from using an accelerating download managers. There must be a way.