Emailing passwords is no proof of storing passwords as plain text

There is a site named plaintextoffenders.com which lists sites which they claim store plain text passwords, i.e. not hashed or encrypted. As proof they let users email screenshots to them.

Many of the screenshots looks like this:

Welcome XXX,

bla bla,

Username: XXXX
Password: XXXX

or changed the password

Dear YYY,

You have successfully changed your password to: XXXX

There is nothing that says that those passwords is stored in plain text in the database. When you register your account or change the password you do type it in the HTML form. Hence it’s sent as plain text to the web server, which then can be used to generate the welcome email.

The only time you *might* have proof of someone storing your password as plain text is if you can request it (like a “forgot password” form). The password might not have been hashed, but it can still have been encrypted. It’s not as secure as hashing (if a potential hacker gets access to the encryption key), but more secure than storing plain text.

Update

I’ve misinterpreted what their goal was. This page explains it.

Email using port 25 is not secure. But most email providers today uses SSL when sending and retrieving emails, which means that man in the middle attacks are not possible. You are only vulnerable for the “email attacks” if the attacker has done the following:

1. Gain access to the router that you or the web site is on (or hacked your computer)
2. Your email provider do not use secure transfers of emails (as most do today).

The chance is imho quite slim which makes this security issue trivial compared to others.

What I’m saying that it’s always important to shed a light on security problems, but don’t scare the users by making them sound bigger than they are.


ADO.NET, the right way

ADO.NET is actually quite powerful if you use it correctly. This post will teach you everything from making your ADO.NET code driver independent to how to implement the repository pattern and unit of work. This is the follow up post of my “Datalayer, the right way” post. The purpose is to demonstrate that ADO.NET can be used as an alternative to OR/Ms.

Continue Reading




Solved: Getting 401 Unauthorized while calling an ASMX service using windows authentication

Today I’ve spent almost the whole day to figure out why an application (COM+) couldn’t authenticate against a ASMX web service. Using my favorite networking tools Wireshark and HTTP Fiddler I saw that the credentials didn’t get included in the initial request, and no other request was made when the 401 challenge came from the web service.

Continue Reading


Griffin.Decoupled – Winforms sample application

I’ve created a small winforms sample application to demonstrate the features of Griffin.Decoupled. I’ve intentionally kept it small to just demonstrate the core features. This post won’t get into the details of how to bootstrap the framework. There are several samples for that. Instead I’ll show how you can put all pieces together using RavenDB as backend.

Continue Reading


Griffin.Networking – Added support for HTTP ranges

Added support for partial file downloads (content ranges)

Someone requested that I should add support for the Range headers in the HTTP protocol. I’ve done that now. But let’s back up a bit first.

In Griffin.Networking you can send files no matter the file size (GB files are no problem). What you do is simply to invoke Send() in your service class. Here is an example:

public class YourService : IServiceService
{
	public override void HandleReceive(object message)
	{
		var buffer = (byte[])message;
		// check message here
		
		var fileStream = new FileStream(@"C:MyFilesSomeVeryLargeFile.zip", FileMode.Open,
                                                FileAccess.Read, FileShare.ReadWrite);

		Context.Send(fileStream);
	}
}

That’s it. The framework will take care of the file sending, sending one piece at a time (the size of the piece is determined by the buffer pool size that you defined when creating the server).

Dealing with ranges manually

In a custom tailored server (i.e. you just use the HTTP protocol implementation from Griffin.Networking) you do it like this:

var rangeHeader = request.Headers["Range"];
if (rangeHeader != null && !string.IsNullOrEmpty(rangeHeader.Value))
{
	var response = request.CreateResponse(HttpStatusCode.PartialContent, "Roger, you'll get partial content");
	response.AddHeader("Accept-Ranges", "bytes");
	var fileStream = new FileStream(@"SomeFilePath", FileMode.Open,	FileAccess.Read, FileShare.ReadWrite);

	// parse requested ranges.
	// we can parse all, but currently do only support one in the ByteRangeStream
	var ranges = new RangeCollection();
	ranges.Parse(rangeHeader.Value, (int)fileStream.Length);
	response.AddHeader("Content-Range", ranges.ToHtmlHeaderValue((int)fileStream.Length));

	// move to the correct position in the inner stream.
	// will also report the correct range size instead of the entire file size
	// will support serving multiple ranges in the same response in the future.
	response.Body = new ByteRangeStream(ranges, fileStream); 
	Send(response);
}

// all other request processing here.

A full example can be found in the HTTP protocol sample folder at github.

Using the webserver

I’ve moved the WebServer implementation from Griffin.Networking repository to a seperate one at Github called Griffin.WebServer. It contains a file module which supports caching, partial file downloads and listing files (if enabled).

You can configure a HTTP server which serves static files like this:

// Module manager handles all modules in the server
var moduleManager = new ModuleManager();

// Let's serve our downloaded files (Windows 7 users)
var fileService = new DiskFileService("/", string.Format(@"C:Users{0}Downloads", Environment.UserName));

// Create the file module and allow files to be listed.
var module = new FileModule(fileService) {ListFiles = true};

// Add the module
moduleManager.Add(module);

// And start the server.
var server = new HttpServer(moduleManager);
server.Start(IPAddress.Any, 8080);

The WebServer is still work in progress. The pieces are however coming together pretty well.



New version of Griffin.Networking – A networking library for .NET

I’ve refactored Griffin.Network quite a lot (I did say that it was still an early release). The new version is called v0.5 (the library is taking shape, but there is still some things to take care of).

Highlights:

1. The pipeline is no longer mandatory
2. I’m using the Async methods instead of Begin/EndXxxx
3. The buffer management is a more effecient
4. It’s easier to work with the buffers
5. Introducing messaging support

Continue Reading


Feature request: Visit the oldest bookmark

Can someone please make an extension for Google Chrome which once a week suggest that I should visit my oldest bookmark (i.e. the one that I haven’t clicked on for the longest time).

In that way I can start cleaning up my bookmarks.


Pages:12345678...14