Definitely fake

Messages asking for personal information:  http://mail.google.com/support/bin/answer.py?hl=en&answer=8253

Reporting suspicious messages:  http://mail.google.com/support/bin/answer.py?hl=en&answer=29381

I ‘ve received this message:

Estimado Usuario de Gmail,

Sus dos correos entrantes se colocaron en estado de espera debido a la reciente actualización de nuestra base de datos. Con el fin de recibir los mensajes haga clic aquí para iniciar sesión y esperar la respuesta de nuestro servidor.

Les pedimos disculpas por las molestias que este cambio les pueda ocasionar y gracias por su comprensión.

Atentamente,

Atención al Cliente.”

It’s a scam called phishing to try steal your private info / password ,  click on the down arrow at the top right of the email and select “Report phishing” from the drop down menu.  This will help Gmail warn others that the email is a scam , or use the following form:  http://mail.google.com/support/bin/request.py?contact_type=abuse_phishing

some info :

never give out your password to emailed requests , any email from Google must end @google.com – also click the show details arrow and make sure the domain you see next to the ‘mailed-by’ or ‘signed-by’ lines matches the sender’s email address. If you see messages claiming to be from google.com, but are not properly authenticated as coming from google.com, then they are, phishing messages.   Google will never ask you for your password (other than in their normal sign in screens, etc.). If you ever get an email asking for your password, you can be guaranteed that it isn’t from Google/Gmail.

DNS cache in Firefox

Clear DNS cache in Firefox

 

During the day I switch my VPN connection on and off several times. When I try to hit a server inside my company’s network while the VPN connection is down, it obviously fails and because I’m using OpenDNS every hostname resolves to an ip-address (in this case an ip-address of a server at OpenDNS).

I connect to VPN and then reload the page in Firefox and the same error page shows up. The reason for this behavior is Firefox’s internal DNS cache. The only remedy at that point is to close Firefox and restart it, which clears the in-memory DNS cache.

However, there’s a solution that does not require a restart.

  1. type about:config in Firefox’s address bar
  2. acknowledge the warning that appears next
  3. find an entry called network.dnsCacheExpiration and set it’s value to 0
  4. if there’s no such entry, create a new integer item with the name above and a value of 0
  5. now go back and change the value to 3600

In step 3 (or 4) we tell Firefox that the expiration time for DNS cache is 0 seconds, which means that cache entries expire immediately, essentially clearing the existing cache. In step 5 we go back to the standard 3600 seconds (1 hr) cache expiration. The net effect of these steps is an empty DNS cache, meaning that the next time you hit the trouble server above, Firefox will attempt to resolve the hostname to an ip-address.

Privly

A new tool under development by Oregon State computer scientists could radically alter the way that communications work on the web. Privly is a sort of manifesto-in-code, a working argument for a more private, less permanent Internet.

The system we have now gives all the power to the service providers. That seemed to be necessary, but Privly shows that it is not: Users could have a lot more power without giving up social networking. Just pointing that out is a valuable contribution to the ongoing struggle to understand and come up with better ways of sharing and protecting ourselves online.

“Companies like Twitter, Google, and Facebook make you choose between modern technology and privacy. But the Privly developers know this to be false choice,” lead dev Sean McGregor says in the video below. “You can communicate through the site of your choosing without giving the host access to your content.”

Through browser extensions, Privly allows you to post to social networks and send email without letting those services see “into” your text. Instead, your actual words get encrypted and then routed to Privlys servers (or an eventual peer-to-peer network). What the social media site “sees” is merely a link that Privly expands in your browser into the full content. Of course, this requires that people who want to see your content also need Privly installed on their machines.

Google Privacy Policy

We’re getting rid of over 60 different privacy policies across Google and replacing them with one that’s a lot shorter and easier to read. Our new policy covers multiple products and features, reflecting our desire to create one beautifully simple and intuitive experience across Google.
We believe this stuff matters, so please take a few minutes to read our updated Privacy Policy and Terms of Service at http://www.google.com/policies. These changes will take effect on March 1, 2012. 

Got questions?
We’ve got answers.
Visit our FAQ at http://www.google.com/policies/faq to read more about the changes. (We figured our users might have a question or twenty-two.)

employers asking for Facebook passwords

SEATTLE (AP) — Two U.S. senators are asking Attorney General Eric Holder to investigate whether employers asking for Facebook passwords during job interviews are violating federal law, their offices announced Sunday.

Troubled by reports of the practice, Democratic Sens. Chuck Schumer of New York and Richard Blumenthal of Connecticut said they are calling on the Department of Justice and the U.S. Equal Employment Opportunity Commission to launch investigations. The senators are sending letters to the heads of the agencies.

The Associated Press reported last week that some private and public agencies around the country are asking job seekers for their social media credentials. The practice has alarmed privacy advocates, but the legality of it remains murky.

On Friday, Facebook warned employers not to ask job applicants for their passwords to the site so they can poke around on their profiles. The company threatened legal action against applications that violate its long-standing policy against sharing passwords.

A Facebook executive cautioned that if an employer discovers that a job applicant is a member of a protected group, the employer may be vulnerable to claims of discrimination if it doesn’t hire that person.

Personal information such as gender, race, religion and age are often displayed on a Facebook profile — all details that are protected by federal employment law.

“We don’t think employers should be asking prospective employees to provide their passwords because we don’t think it’s the right thing to do. While we do not have any immediate plans to take legal action against any specific employers, we look forward to engaging with policy makers and other stakeholders, to help better safeguard the privacy of our users,” Facebook said in a statement.

Not sharing passwords is a basic tenet of online conduct. Aside from the privacy concerns, Facebook considers the practice a security risk.

“In an age where more and more of our personal information — and our private social interactions — are online, it is vital that all individuals be allowed to determine for themselves what personal information they want to make public and protect personal information from their would-be employers. This is especially important during the job-seeking process, when all the power is on one side of the fence,” Schumer said in a statement.

Specifically, the senators want to know if this practice violates the Stored Communications Act or the Computer Fraud and Abuse Act. Those two acts, respectively, prohibit intentional access to electronic information without authorization and intentional access to a computer without authorization to obtain information.

The senators also want to know whether two court cases relating to supervisors asking current employees for social media credentials could be applied to job applicants.

“I think it’s going to take some years for courts to decide whether Americans in the digital age have the same privacy rights” as previous generations, American Civil Liberties Union attorney Catherine Crump said in a previous interview with the AP.

The senators also said they are drafting a bill to fill in any gaps that current laws don’t cover.

Maryland and Illinois are considering bills that would bar public agencies for asking for this information.

In California, Democratic Sen. Leland Yee introduced a bill that would prohibit employers from asking current employees or job applicants for their social media user names or passwords. That state measure also would bar employers from requiring access to employees’ and applicants’ social media content, to prevent employers from requiring logins or printouts of that content for their review.

In Massachusetts, state Democratic Rep. Cheryl Coakly-Rivera also filed a similar bill Friday that also expands to include personal email. Her measure also bars employers from “friending” a job applicant to view protected Facebook profiles or using similar methods for other protected social media websites.

___

Manuel Valdes can be reached at https://twitter.com/ByManuelValdes.

Nigerian email scams

Nigerian email scams have become nearly as commonplace as the Internet itself. But one Australian woman wound up in jail after turning the tables–to the tune of $30,000–on a group of con artists.
The Courier-Mail reports that Sarah Jane Cochrane-Ramsey, 23, was employed as an “agent” in March 2010 by the Nigerians, but didn’t know they were scam artists. Her “job” was to provide access to an Australian bank account opened in her name where the Nigerians could then transfer money they had received from a phony car sales website. Cochrane-Ramsey was told she could keep eight percent of the transfers.
But, then she decided to steal from the thieves themselves. According to the Courier-Mail, she received two payments, totaling $33,350, but spent most of it on herself.
If you’re not familiar with the so-called Nigerian Scam, also known as the (419) scam, or Advanced Fee Fraud, here’s a brief explainer: the fraud works by convincing an individual to give money and/or bank account access to a third-party in exchange for future financial rewards.
Most commonly, the scam artist will claim to be a wealthy Nigerian individual looking to move his vast financial resources to another country. He then promises the fraud victim a hefty payment in exchange for a temporary loan or bank account access in order to facilitate the move. Of course, the fraud victim never receives the promised payout and instead usually ends up losing thousands of dollars in the process. According to Scam Busters, the Advance Fee Fraud scams often target small businesses and charities. And while the scam has been around for years, the U.S. Financial Crimes Division of the Secret Service still receives a reported 100 calls a day from people claiming to be victims of a (419) crime.
But, back to the Cochrane-Ramsey case. The real victims who thought they were buying cars online reported the scam to the police, who traced the account back to Cochrane-Ramsey. She was ordered to appear in Brisbane District Court and plead guilty to one count of aggravated fraud.

For now, the court judge is allowing Cochrane-Ramsey time to come up with the money to pay off the fraud victims while she awaits sentencing in March.
Interestingly, Cochrane-Ramsey is not the first person to turn the tables on Nigerian scammers. In 2008, the radio program This American Life ran a story on some anonymous pranksters who sent a Nigerian scam artist on a wild goose chase that spanned 1,400-miles into war-torn Chad for a promised cash payout at a local Western Union branch.
And they convinced him to do this while carrying an anti-Muslim/pro-George W. Bush note, which stated his intention to rob the Western Union. Their entire plan was spelled out on this website, dedicated to turning the tables on Internet con artists (Warning: contains Not Safe for Work language).
You can listen to the episode of This American Life here.

costing plans by mobile networks

Analysis firm Ovum studied global use of popular services like Whatsapp, Blackberry Messenger and Facebook chat.

It concluded that mobile operators must “work together to face the challenge from major internet players”.

Industry experts say operators can offset any losses through effective costing plans by mobile networks.

The report gathered usage statistics from the leading social messaging applications typically used on smartphones across the world.

As well as well-known names from popular social networks in the Western world, the study also included apps such as MXit – a massively popular program used mainly in South Africa.

Social messaging apps make use of a smartphone’s internet connection to send messages rather than the usually far costlier SMS – short message service – system.

ASP.Net Security

tecnologias ASP.NetMake sure you are very familiar with the following terms:

  • Authentication. Positively identifying the clients of your application; clients might include end-users, services, processes or computers.
  • Authorization. Defining what authenticated clients are allowed to see and do within the application.
  • Secure Communications. Ensuring that messages remain private and unaltered as they cross networks.
  • Impersonation. This is the technique used by a server application to access resources on behalf of a client. The client’s security context is used for access checks performed by the server.
  • Delegation. An extended form of impersonation that allows a server process that is performing work on behalf of a client, to access resources on a remote computer. This capability is natively provided by Kerberos on Microsoft® Windows® 2000 and later operating systems. Conventional impersonation (for example, that provided by NTLM) allows only a single network hop. When NTLM impersonation is used, the one hop is used between the client and server computers, restricting the server to local resource access while impersonating.
  • Security Context. Security context is a generic term used to refer to the collection of security settings that affect the security-related behavior of a process or thread. The attributes from a process’ logon session and access token combine to form the security context of the process.
  • Identity. Identity refers to a characteristic of a user or service that can uniquely identify it. For example, this is often a display name, which often takes the form authority/user name.

Principles

There are a number of overarching principles that apply to the guidance. The following summarizes these principles:

  • Adopt the principle of least privilege. Processes that run script or execute code should run under a least privileged account to limit the potential damage that can be done if the process is compromised. If a malicious user manages to inject code into a server process, the privileges granted to that process determine to a large degree the types of operations the user is able to perform. Code that requires additional trust (and raised privileges) should be isolated within separate processes.The ASP.NET team made a conscious decision to run the ASP.NET account with least privileges.
  • Use defense in depth. Place check points within each of the layers and subsystems within your application. The check points are the gatekeepers that ensure that only authenticated and authorized users are able to access the next downstream layer.
  • Don’t trust user input. Applications should thoroughly validate all user input before performing operations with that input. The validation may include filtering out special characters. This preventive measure protects the application against accidental misuse or deliberate attacks by people who are attempting to inject malicious commands into the system. Common examples include SQL injection attacks, cross-site scripting attacks, and buffer overflow.
  • Use secure defaults. A common practice among developers is to use reduced security settings, simply to make an application work. If your application demands features that force you to reduce or change default security settings, test the effects and understand the implications before making the change.
  • Don’t rely on security by obscurity. Trying to hide secrets by using misleading variable names or storing them in odd file locations does not provide security. In a game of hide-and-seek, it’s better to use platform features or proven techniques for securing your data.
  • Check at the gate. You don’t always need to flow a user’s security context to the back end for authorization checks. Often, in a distributed system, this is not the best choice. Checking the client at the gate refers to authorizing the user at the first point of authentication (for example, within the Web application on the Web server), and determining which resources and operations (potentially provided by downstream services) the user should be allowed to access.If you design solid authentication and authorization strategies at the gate, you can circumvent the need to delegate the original caller’s security context all the way through to your application’s data tier.
  • Assume external systems are insecure. If you don’t own it, don’t assume security is taken care of for you.
  • Reduce surface area. Avoid exposing information that is not required. By doing so, you are potentially opening doors that can lead to additional vulnerabilities. Also, handle errors gracefully; don’t expose any more information than is required when returning an error message to the end user.
  • Fail to a secure mode. If your application fails, make sure it does not leave sensitive data unprotected. Also, do not provide too much detail in error messages; meaning don’t include details that could help an attacker exploit a vulnerability in your application. Write detailed error information to the Windows event log.
  • Remember you are only as secure as your weakest link. Security is a concern across all of your application tiers.
  • If you don’t use it, disable it. You can remove potential points of attack by disabling modules and components that your application does not require. For example, if your application doesn’t use output caching, then you should disable the ASP.NET output cache module. If a future security vulnerability is found in the module, your application is not threatened.

The following steps identify a process that will help you develop an authentication and authorization strategy for your application:

  1. Identify resources
  2. Choose an authorization strategy
  3. Choose the identities used for resource access
  4. Consider identity flow
  5. Choose an authentication approach
  6. Decide how to flow identity

Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication