Bitcoin Forum
November 16, 2024, 11:18:44 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Windows IIS Web Wallet  (Read 3001 times)
doof (OP)
Hero Member
*****
Offline Offline

Activity: 765
Merit: 503


View Profile WWW
February 02, 2014, 04:53:07 AM
 #1

Motivation
Love or hate Microsoft Windows, enterprise and large business run it and continue to adopt Windows and Microsoft products [1][2][3].   While there are a lot of good LAMP products, I believe there needs to more Windows based solutions for enterprise adoption.  Enterprise will require a wallet that runs on premises, using technology stacks they currently use like Microsoft SQL Server, SSRS and OLAP Cubes, BizTalk, Forefront.

Design goals
 
  • Run on Windows Server 2008R2 and above
  • Run as a web app on IIS 7 and above
  • Be secured by existing corporate authentication providers, like Active Directory
  • Configurable by existing sys admins, using familiar interfaces (MMC, Web.config)
  • Log go sources like Event Viewer
  • Backup of private keys inline with existing backup solutions
  • Be estensibile via JSON Restful and SOAP interfaces
  • Cross browser HTML5 web interface, with "hackable" urls

I have been working on a c# MVC web app to meet the above requirements.  The node runs as a Windows Service and exposes WCF endpoints too.  The application users AD groups to secure the site and features. 

There are still a lot of features I won't to add and a few bugs to fix, before I publish the source code.





[1] ME Bank Adopts SQL Server and Windows Server 2012 http://www.microsoft.com/australia/presspass/post/ME-Bank-Adopts-SQL-and-Windows-Server-2012
[2] ING Bank http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=710000001710
[3] Bank of Queensland BizTalk http://www.itnews.com.au/News/267460,bank-of-queensland-finance-rebuilds-it-systems.aspx
patricktim
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
February 02, 2014, 07:54:35 AM
 #2

need more info on how secure is Web Wallet?

doof (OP)
Hero Member
*****
Offline Offline

Activity: 765
Merit: 503


View Profile WWW
February 02, 2014, 09:07:58 AM
 #3

Sure, at the moment it interfaces with bitcoind using RPC.  That is secured by standard procedures, i.e., only allowing RPC calls from localhost or an internal subnet.

The IIS server should only allow https from internal too.  

As mentioned, there is a lot todo, one tasking being an installer guide.   Enterprise sys admins would apply their own standard firewall, encrypting web.config etc and IIS hardening procedures too.   Note that bitcoin.conf persists RPC username and password in plain text, so it is up to the sys admin to harden the server.
doof (OP)
Hero Member
*****
Offline Offline

Activity: 765
Merit: 503


View Profile WWW
February 02, 2014, 11:07:54 AM
 #4

Thanks for your opinions gweedo.   A web based currency needs web based wallets.  Your comments are as backward thinking as banks who stated in the 90's they would never do online banking.
doof (OP)
Hero Member
*****
Offline Offline

Activity: 765
Merit: 503


View Profile WWW
February 02, 2014, 11:09:19 AM
 #5

"Also you do know that PHP runs just fine under IIS so yeah I don't see any purpose to this project"  Exactly what a PHP developer would say.  When a Bank runs a team of c# developers, there is a very real reason for this project.   

From a consultant, thats a very immature comment.
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1030


bits of proof


View Profile WWW
February 02, 2014, 11:20:02 AM
 #6

Thanks for your opinions gweedo.   A web based currency needs web based wallets.  Your comments are as backward thinking as banks who stated in the 90's they would never do online banking.

Having a web interface is fine. Having bitcoins (the keys) stored on a the web site for thousands of user is exactly backward thinking of online banking that we want to leave behind.

Bitcoin should be owned by the user in secure devices like TREZOR and web applications should only help them to follow, prepare, report ... but not sign for them.
doof (OP)
Hero Member
*****
Offline Offline

Activity: 765
Merit: 503


View Profile WWW
February 02, 2014, 11:26:43 AM
 #7

Thanks grau.  I plan on swapping out bitciond later for a open source c# implementation that I am involved with and has been posted here.  The project isn't designed to be a multi wallet solution.  The web interface should only be exposed on an internal network.

A hardware appliance would be an ideal solution.
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1030


bits of proof


View Profile WWW
February 02, 2014, 04:44:52 PM
 #8

Well most banks run java backends not C# or php.

correct.

I worked in a few big banks and never met PHP.
C# was sometimes used on the desktop, but never on a backend. Have not seen IIS either.
flower1024
Legendary
*
Offline Offline

Activity: 1428
Merit: 1000


View Profile
February 02, 2014, 04:47:16 PM
 #9

Well most banks run java backends not C# or php.

correct.

I worked in a few big banks and never met PHP.
C# was sometimes used on the desktop, but never on a backend. Have not seen IIS either.

same here...
though i saw COBOL and perl in the backend too Wink (and some REALLY ugly terminal to web converter ughhh)
nasamanBoy
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
February 06, 2014, 05:03:09 PM
 #10

That the latter are right, COBOL and Perl in the backend too.....
Cyrus
Ninja
Administrator
Legendary
*
Online Online

Activity: 3962
Merit: 3153



View Profile
February 07, 2014, 12:54:23 AM
 #11

COBOL still used around here as well in banks/insurance companies backends.

r3wt
Hero Member
*****
Offline Offline

Activity: 686
Merit: 504


always the student, never the master.


View Profile
February 07, 2014, 12:59:24 AM
 #12

COBOL still used around here as well in banks/insurance companies backends.

True, i'm enrolling in college and the advisor recommended i take the course on cobol for enterprise development/software engineering.

My negative trust rating is reflective of a personal vendetta by someone on default trust.
artw1982
Full Member
***
Offline Offline

Activity: 196
Merit: 100


View Profile
February 07, 2014, 03:53:33 AM
 #13

Being a C# developer I love seeing this project. However, I do agree that hot wallets are a huge risk. Keeping everyone's coin in a single wallet.dat is scary. What if you were to write a class that generated the keys in memory, encrypted them with the users password as key, then save each users wallet to it's own .dat file. Never storing their password. Not using the bitcoind at all for key generation.

If you're looking for someone to collaborate with or discuss ideas with I can help.
flower1024
Legendary
*
Offline Offline

Activity: 1428
Merit: 1000


View Profile
February 07, 2014, 10:30:48 AM
 #14

Being a C# developer I love seeing this project. However, I do agree that hot wallets are a huge risk. Keeping everyone's coin in a single wallet.dat is scary. What if you were to write a class that generated the keys in memory, encrypted them with the users password as key, then save each users wallet to it's own .dat file. Never storing their password. Not using the bitcoind at all for key generation.

If you're looking for someone to collaborate with or discuss ideas with I can help.

blockchain.info's does this and it works quite well
but i would never put all my coins in one basket again.

what i might use: a balance watcher which allows to send by providing a privkey. after sending i would not use this address ever again
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
March 08, 2014, 06:57:13 PM
 #15

Any progress on this.  Going to put it up on github? Curious to see the implementation.  While I don't like public eWallets I can see this being useful on a corporate intranet. 
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!