|
You probably mean encryption - hash is one way...
Anyway there is no use of hashing/encrypting data before post. If hacker has access to the client he can see the data before hash/encryption too!
The reason you can see the plain data is:
1. You run sniffing software (what do you use) on the client or server. That's (hopefully not the way hacker does it)
2. You do not use secure protocols, like HTTPS...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Thanks, I was planning on using a hashing method rather than encryption as encryption could be undone if you knew the algorithm/keys etc, hashing could be matched but not undone, this gets me some where for securing the password without SSL, from the research done today I may just go SSL.
|
|
|
|
|
In most cases there is an advantage to NOT to invent the wheel  ...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
The problem is that hashing the password on the client doesn't solve anything, and can actually make your application less secure.
You want to hash the password on the client in case someone can sniff the traffic, so that they won't be able to see the password. But if they can sniff the traffic, they don't need to see the password; they can just submit the password hash instead, since that's what your server is expecting.
Worse, if they managed to get hold of your database of password hashes, they wouldn't need to try to crack them; they could just submit the hashes as if they were plain-text passwords.
SSL is definitely the way to go. Let the infrastructure protect your passwords in-flight, and leave the hashing on the server where it belongs. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
There are javascript based md5 hash routines which you can use on the client and send sever side for storage. If someone sniffs it they still don't know what the password value is. This works because the password entered into the log-in page will be the real password which gets hashed server side for comparison. Of course, you will have to use the same routine server side before comparing the values.
|
|
|
|
|
But now the server isn't expecting the password; it's expecting the password hash.
If someone can sniff the network traffic, they won't be able to see the password, but they'll be able to see the password hash. And that's all they need to see.
An attacker who captures the password hash in-flight can simple submit a request with that hash, and the server will happily authenticate them.
Worse, if the attacker compromises the database and gets hold of your hashed passwords, they can authenticate as any user.
Client-side hashing doesn't make your application more secure. If anything, it makes it less secure.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Clearly a secure connection is what is required but it doesn't matter if the password is passed or the hash value is passed, if someone gains access to the data that you are directly authenticating to then the result is the same regardless, not more or less, just the same. If you are using .Net you can encrypt the values using settings in the config file, that would probably be the best technique.
|
|
|
|
|
Michael_Cox wrote: if someone gains access to the data that you are directly authenticating to then the result is the same regardless
Not quite.
If an attacker is sniffing the network traffic between the client and the server, then there's no hope either way.
However, if the attacker gets hold of a list of username and hashed passwords:
- If you're hashing the password on the server, then the attacker has to guess the password before they can authenticate.
- If you're hashing the password on the client, then the attacker can immediately authenticate as any user.
Your server isn't checking that the user knows the password, only that they know the hash of the password.
If you install an SSL certificate, and ensure that your login pages are only ever served over HTTPS, then you protect the data in-flight. But if you're going to do that, then why would you bother hashing the passwords on the client? Nobody can see the network traffic, so the argument for client-side hashing is gone.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Hello
I am trying to follow this tutorial
[^]
with an MS Access database in VB.NET.
In the code example (for Passwordreset.aspx), there is a reference to UserID. Is this the first column in the database, please?
This is what I have in my db:
http://www.bayingwolf.com/tutorial.jpg[^]
Would I just need to add a UserID column in order to follow the tutorial. There is also a reference in the Passwordreset.aspx code to:
<asp:SqlDataSource ID="SqlDataSource1" runat="server"
Would I just replace that with my own MS Access source?
Thank you.
|
|
|
|
|
Member 8761667 wrote: there is a reference to UserID. Is this the first column in the database, please?
It doesn't really matter. You just need to go through the code and understand it so that you can tweak it to work for you. Code is generally not something you can just copy and paste and have work right away. You'll need to understand the various pieces so you can implement it.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Thanks for your message, Ryan.
Appreciated!
|
|
|
|
|
hello can i ask for help on how to create an application that can sent email. thank you 
|
|
|
|
|
You could ask Google and you will find many samples.
|
|
|
|
|
|
Sure you can ask. Do you have a specific question?
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Hi Guys,
Am currently working as Junior .Net Developer,
However, Am requested by my manager to develop a web page called staff deployment plan that will involve two GridViews, that is the Parent GridView and Child GridView. The Parent GridView will display two columns which are EmployeeNames and WorkingDays - the working days column is a heading of Child GridView and the child gridview displays columns as current working days for example: the month of November 2014 has 20 working days excluding weekends and public holidays in South Africa, so the columns for child gridview are like this: 3 Nov, 4 Nov, 6 Nov...etc The problem that am experiencing now: Is to add LinkButton for each column on the Child GridView and to create command event for each linkbutton inside a child gridview (remember this child gridview is inside a parent gridview) and the link button when is click it should display a popup window. Any help in terms of how to accomplish this will be highly appreciated Kindest Regards Lucky Khoza
|
|
|
|
|
in child gridview
<templatefield>
<itemtemplate>
<asp:linkbuttin id="lnk1" runat="server">
|
|
|
|
|
I need some help with the fundamentals.
I have a VB.Net Desktop app that I am converting to a Web App. I do not understand how the variable are stored/saved, etc.
Can something walk me through this?
The structure is the following:
1. Visual Studio 2013
2. Startup main page is a C# module. This does screen / view handling and OAuth authentication.
3. It references a class that is written in VB.2013 (this has the main business logic). Call this vbMain.
4. The VB.2013 class invokes another VB.2013 class (call it vbServHandler. This 2nd VB class handles all the real interface to the web services (REST) that was authenticated in the C# module.
It seem that the variable in the 1st VB Class (vbMain) are not preserved across requests but those in the 2nd VB class are.
I just do not understand this.
Can somesome please give me some?
|
|
|
|
|
The best I can do here is this, perhaps someone else can explain it better, but looks like there are no takers on this post.
A windows app, is really different. Within a windows app, you have access to so many resources, and can make global buffers, that can be used from form or dialog to form or dialog.
A web page, is a 1 time deal. you create the web page, and when done, or the page is unloaded, everything dies with it. When you create another page, you start all over again, and the process repeats. There are ways to store information from page to page, or transfer information from page to page, but that's provided by the web server or through the use of hyperlink query strings.
[Sort of an Anwser]
Some of the code is reusable, the rest just supports the windows controls and objects.
You really need to start from scratch, and design a web based system with the UI first. Now write the navigation part, 1 page to the other, make it look pretty, then start plugging in your logic from the other program, 1 piece at a time until it works correctly.
Sounds to me like you have very little experience at building a web application, and mid level experience at building a windows application. It's important to understand the different between the 2 before you try to port the windows app to a web app.
There's no magic or easy way to do it.
|
|
|
|
|
Thanks
I understand that there is no magic and no converter and that each page is new and any variables should be as initialized when built or saved in either viewState, SessionState, ApplicationState a cookie or other external source.
This does not explain why variables in the 2nd VB class (vbServHandler) has new data in it while the 1st (vbMain) does not. What would cause this?
|
|
|
|
|
It sounds like vbServHandler is using Shared fields.
You should generally avoid Shared fields in ASP.NET applications unless you really know what you're doing. For example, the data in the fields will be shared across all requests from all users, which means you could easily end up showing data meant for user A to user B by mistake.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
They are NOT shared. I think it may be when a button control is hit on the page that the vbServHander is not getting re-initialized (vbServHandler variables still have data). I have done this:
1. By just click in the upload button on the vbMain button multiple times.
2. Clicking on the C# menu button (Upload) to reload the page.
3. Going back to the main page and clicking on the Upload button to reload the upload page.
4. Even refreshing the main home page via F5.
In all cases the constructor for vbMain (i.e. sub new) shows data in the vbServHandler variables.
I am programming around this (I actually think it is better) but just do not understand it.
|
|
|
|
|
If the variables are persisted between requests to your site, and they're not stored in application or session state, then either they're stored in Shared fields, or the instance of the containing class is stored in a Shared field somewhere.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
They are not saved anywhere.
If they are in some shared object then I do not know where it could be.
Here is the definition of the object I was checking in the Sub new of vbMain.
Public AccountCollection As Collection
in what I was calling vbServHandler. Real name is QBAPIV3Cl which is part of DLL QBAPIV3VS2013.
This is invoked via by vbMain
Imports QBOAPIV3VS2013
.
.
Public aQB As New QBOAPIV3VS2013.QBAPIV3Cl()
which is defined in a module within vbMain.
.
.
Which is referenced by the C# Web App
using vbMainDLL;
In the C# program it is defined as
vbMainDLL.vbMain vbMain;
vbMain = new vbMain(TheRealmID,TheAccessToken,TheAccessTokenSecret,
TheConsumerKey,TheConsumerSecret,
TheContext,TheDataService,
pOutReason: ref pOutReason);
The Sub New for vbMain has aQB.accountcollection.count
Referenced object has a value of nothing the first time.
then 121 every other time. I would expect a value of nothing each time.
The c# program has no references to the aQB class/QBOAPIV3VS2013.QBAPIV3Cl.
So what am I missing?
|
|
|
|
|
QuickBooksDev wrote: which is defined in a module within vbMain.
A Module is effectively a class in which every member is Shared. If your fields are stored in a Module, they they're Shared by definition.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
