Hi all,
I have a program that serves client programs. The server has a login
password, which has to be used by each client for logging in. So, when
the client connects, it sends a string with a password, which is then
validated on the server side. The problem is obvious: anyone can get
the password just sniffing the network.
How can I solve this?
Daniel
36  3218 
"dcrespo" <dc*****@gmail.com> writes: I have a program that serves client programs. The server has a login
password, which has to be used by each client for logging in. So, when
the client connects, it sends a string with a password, which is then
validated on the server side. The problem is obvious: anyone can get
the password just sniffing the network.
How can I solve this?
If you really want to do it right, use SRP, <http://srp.stanford.edu>.
simplest approach is to 1 way hash the password ... perhaps using md5
normally with passwords the server only has to check if it is the same
word, assuming the same hash algorithms the same hash value can be
created at client.
Its not hugely secure ... anyone sniffing can grab your hash value and
then try to crack it at their leisure. It would be better to communicate
over ssl.
Anyone know of a simple ssl api in python :-)
dcrespo wrote: Hi all,
I have a program that serves client programs. The server has a login
password, which has to be used by each client for logging in. So, when
the client connects, it sends a string with a password, which is then
validated on the server side. The problem is obvious: anyone can get
the password just sniffing the network.
How can I solve this?
Daniel
Peter Tillotson wrote: simplest approach is to 1 way hash the password ... perhaps using md5
No, it isn't - see below.
normally with passwords the server only has to check if it is the same
word, assuming the same hash algorithms the same hash value can be
created at client.
Unfortunately this means that the client sends the same string every
time the user authenticates.
Its not hugely secure ... anyone sniffing can grab your hash value and
then try to crack it at their leisure. It would be better to communicate
over ssl.
It's not even that secure: all they have to do is replay the data
sniffed from the server and they too can authenticate themselves. They
don't have to know what the plain-text password is.
Anyone know of a simple ssl api in python :-)
A safer way would be to use some sort of challenge-response mechanism,
where the server presents a challenge C to the client, which then
computes some function of both C and the plain-text password provided by
the user. The server then authenticates by performing the same
computation on C and the known password.
As long as the server uses a different challenge each time then this is
at least secure from replay attacks. But this scheme does have the
weakness that the server must know the password of each user.
For something even more secure, look at OPIE and similar schemes. But
let's not forget that all these schemes only secure the authentication
exchange: they do nothing to protect application data.
regards
Steve
dcrespo wrote:
Hi all,
I have a program that serves client programs. The server has a login
password, which has to be used by each client for logging in. So, when
the client connects, it sends a string with a password, which is then
validated on the server side. The problem is obvious: anyone can get
the password just sniffing the network.
How can I solve this?
Daniel
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
How about an OTP (One Time Password) algorithm? It is described in RFC2289. http://www.faqs.org/rfcs/rfc2289.html
I have a working implementation in Messlib. You can download it an look
at the "MessageSocket.SecureMessageSocket" class.
That is a modified version where a good random generator is used instead
of a finite sequence of passwords.
But it is just example implementation - you can get the idea there and
develop your own. In fact, my class also has support for
encrypting the communication channel, but the OTP algorithm itself only
requires a cryptographically secure hash algorithm and a
good random number generator. These are all included in Python. ;-)
I also tried to use SSL before, but I realized that for "secure
password" type authentication, OTP is much easier to understand and
use. Of course, SSL can be used for securing the communication line
WITHOUT AUTHENTICATION, and it is harder to understand
and use.
Best,
Les
I think you said the same as me:
Client:
Password = "password"
h = Hash(Password)
h is "GddTHww90lze7vnmxG" (whatever)
Sends h over the network to the server.
h is a string, so this approach is simply vulnerable.
SRP seems to be very good, but because I don't know it well, I think
I'll delay it for a while.
Thank you
Hi. I found TSL, a Python Library that supports SRP.
Do you know where can I find a sample client and server code? Thanks
for your help.
On Mon, 10 Oct 2005 08:06:27 -0700, dcrespo wrote: Hi all,
I have a program that serves client programs. The server has a login
password, which has to be used by each client for logging in. So, when
the client connects, it sends a string with a password, which is then
validated on the server side. The problem is obvious: anyone can get
the password just sniffing the network.
How can I solve this?
Daniel
What I've been doing for this, is to:
1) Store two copies of a (symmetric), one on the client host, one on the
server host.
2) When the client wants to connect to the server, have the server
generate a random string of bits, hash the client's password with the
string, and then the random string to the client
3) The client then hashes its copy of the same password with that random
string, and sends the result back to the server
4) The server, upon receiving the correct hash result, provides service
There are a lot of collisions being found in hash algorithms these days.
I haven't heard about any in the RIPEMD family of hash algorithms yet.
Another possibility is to just use Diffie-Helman key exchange (pretty
simple to code the base algorithm in python - I have an implementation
in pure python for you if you want - but I hear that some numbers are
more prone to attack than others, which my code does not attempt to take
into account) to get a shared encryption key on both ends of the
communication, and then encrypt everything with that.
ˇBeautiful and elegant solution!
Two copies of the password: one on the client, the other on the server.
1. Client wants to connect
2. Server generates a random_alphanumeric_string and sends it to the
client
3. Both Client and Server creates a hash string from
<password+random_alphanumeric_string>
4. Client sends the hash string to the server
5. Server compares his hash result with the hash string received from
de client.
I think it is a very good solution, Isn't it?
Daniel
On Mon, 10 Oct 2005 14:29:20 -0700, dcrespo wrote: ˇBeautiful and elegant solution!
Two copies of the password: one on the client, the other on the server.
1. Client wants to connect
2. Server generates a random_alphanumeric_string and sends it to the
client
3. Both Client and Server creates a hash string from
<password+random_alphanumeric_string>
4. Client sends the hash string to the server
5. Server compares his hash result with the hash string received from
de client.
I think it is a very good solution, Isn't it?
Sounds like it, but how is it different from what I just described? :)
Oh, also, I'm not 100% how much the alphanumeric part impacts things. You
may or may not get a better result by using a random string with all bits
random, not just the bits that vary in ASCII for letters and numbers.
Anyway, for an example of this sort of thing, you might look over my
fallback-reboot program at http://dcs.nac.uci.edu/~strombrg/fallback-reboot/
It uses RIPEMD-160 for the hash.
The server side is in C (to reduce dependencies to a bare minimum), but
the client side is in python (for convenience).
On 10 Oct 2005 13:31:51 -0700, dcrespo <dc*****@gmail.com> wrote: Hi. I found TSL, a Python Library that supports SRP.
Do you know where can I find a sample client and server code? Thanks
for your help. http://trevp.net/tlslite/
It comes with examples. I use it in several servers and clients.
Quite simple to impliment.
HTH :)
"dcrespo" <dc*****@gmail.com> writes: Hi. I found TSL, a Python Library that supports SRP.
Do you know where can I find a sample client and server code? Thanks
for your help.
I don't know about TSL, but TLSLite ( www.trevp.net/tlslite) supports SRP.
"dcrespo" <dc*****@gmail.com> writes: 3. Both Client and Server creates a hash string from
<password+random_alphanumeric_string>
4. Client sends the hash string to the server
5. Server compares his hash result with the hash string received from
de client.
I think it is a very good solution, Isn't it?
No. It's vulnerable to dictionary search. Use SRP if you can.
> Sounds like it, but how is it different from what I just described? :)
That's right, but I wanted to rewrite it... I was for confirm my recent
acquired knowlegde :)
With "alphanumeric" I meant the md5 hash (for example).
On Mon, 10 Oct 2005 15:13:14 -0700, Paul Rubin wrote: "dcrespo" <dc*****@gmail.com> writes: [quoted text muted]
No. It's vulnerable to dictionary search. Use SRP if you can.
Where can I learn more about this?
Thanks!
Dan Stromberg <st******@dcs.nac.uci.edu> writes: No. It's vulnerable to dictionary search. Use SRP if you can.
Where can I learn more about this?
http://srp.stanford.edu as already mentioned. Also, RFC 2945
describes an older version (still ok).
On Tue, 11 Oct 2005 01:21:55 +0200, Michael Ströder wrote: Dan Stromberg wrote: [quoted text muted]
http://www.faqs.org/rfcs/rfc2945.html
Ciao, Michael.
OK, thanks for the reference.
I guess I neglected to stress that we're talking about using random
strings of characters, not dictionary words or other weak forms of
user-chosen passwords.
Is there something easily attacked about the original algorithm, if you
use a long, quite random password in combination with a hash algorithm
that hasn't been broken?
If you look over my fallback-reboot package at: http://dcs.nac.uci.edu/~strombrg/fallback-reboot/ you'll see that there's
a small python script that generates a 32 character hex string for the
passwords.
I suppose I probably should rewrite it to not use whrandom though.
Thanks!
dcrespo wrote: Two copies of the password: one on the client, the other on the server.
[snip] I think it is a very good solution, Isn't it?
Ignoring all the other issues, any solution which actually requires the
password to be stored on the server is a bad solution. Administrators
should not have access to user passwords, and in addition users should
not be put in the position of having to trust your server-side security
to keep their passwords (which they might have used on other systems)
from being grabbed by hackers.
-Peter
dcrespo wrote: ¡Beautiful and elegant solution!
Two copies of the password: one on the client, the other on the server.
1. Client wants to connect
2. Server generates a random_alphanumeric_string and sends it to the
client
3. Both Client and Server creates a hash string from
<password+random_alphanumeric_string>
4. Client sends the hash string to the server
5. Server compares his hash result with the hash string received from
de client.
I think it is a very good solution, Isn't it?
In fact this is almost an OTP but be aware!
A man-in-the-middle attack can crack your algorithm. This is beacuse you
create a random string only on one side.
You cannot trust in the connection you are using. You can modify you
algorigthm to be more secure:
1. Client wants to connect
2. Server generates a server_random_alphanumeric_string and sends it to the
client
3. Client generates a client_random_alphanumeric_string and sends it to the
client too
3. Both Client and Server creates a hash string from
<server_random_alphanumeric_string+password+client _random_alphanumeric_string>
4. Client sends the hash string to the server
5. Server compares his hash result with the hash string received from
de client.
This is only a bit difference, but is makes sense. An intuder (who knows
the your algorithm, because getting the code is not as difficult) could
make a fake server to you, and send back HIS string (that is not
random). Suppose we have a weakness in the hash function. The intuder
can exploit this weakness by sending you his special string. The
modified version has the advantage of sending two random strings, this
way the intuder cannot take advantage of possible hash function
weaknesses, because the hash function will be called on a string that is
random for sure.
Best,
Les Ignoring all the other issues, any solution which actually requires the
password to be stored on the server is a bad solution. Administrators
should not have access to user passwords, and in addition users should
not be put in the position of having to trust your server-side security
to keep their passwords (which they might have used on other systems)
from being grabbed by hackers.
Users will always need to trust in the server. The authentication
process ensures that the
client is really talking with the desired server and vice versa. But
even if you know that you
are talking to the right server, you need to trust in the server. The
administrator of the server
has access to all data. Possibly other persons and softwares too.
Passwords are not different
from this point of view.
Les If you really want to do it right, use SRP, <http://srp.stanford.edu>.
This is a bit offtopic here. I read the RFC and I do not see why SRP is
not vulnerable to dictionary attacks.
If I have a working client software then I can use it to reveal
passwords. Isn't it a dictionary attack?
Can you please enlighten me?
Les
Laszlo Zsolt Nagy <ga*****@designaproduct.biz> writes: This is a bit offtopic here. I read the RFC and I do not see why SRP
is not vulnerable to dictionary attacks.
If I have a working client software then I can use it to reveal
passwords. Isn't it a dictionary attack?
Dictionary attack in this context means an eavesdropper records a
session, then compares all the hashed passwords against a word list
offline. If the attacker is allowed to make unlimited online queries,
then he can guess at SRP passwords too. But the host should notice
that and prevent it.
Paul Rubin wrote: Laszlo Zsolt Nagy <ga*****@designaproduct.biz> writes:
This is a bit offtopic here. I read the RFC and I do not see why SRP
is not vulnerable to dictionary attacks.
If I have a working client software then I can use it to reveal
passwords. Isn't it a dictionary attack?
Dictionary attack in this context means an eavesdropper records a
session, then compares all the hashed passwords against a word list
offline. If the attacker is allowed to make unlimited online queries,
then he can guess at SRP passwords too. But the host should notice
that and prevent it.
I see. So the eavesdropper records the random strings and the password
hash value sent.
Having these values, he can try to find a suitable password in his list
that will result in the same communication.
He can do this without having to connect to the server again, just by
replaying the algorithm for a given password
(and the same 'random' strings).
The difference in SRP is that the random strings are private, they will
never be sent over the network.
So they cannot be eavesdropped. Cracking SRP would require to calculate
the dividers of a product of
two very big primes (like in RSA). This is why it is hard to use
dictionary attacks - you cannot replay the
algorithm for a given password.
Thank you, I think I understand now.
Les
Laszlo Zsolt Nagy wrote: Peter Hansen wrote: Ignoring all the other issues, any solution which actually requires
the password to be stored on the server is a bad solution.
Administrators should not have access to user passwords, and in
addition users should not be put in the position of having to trust
your server-side security to keep their passwords (which they might
have used on other systems) from being grabbed by hackers.
Users will always need to trust in the server. The authentication
process ensures that the
client is really talking with the desired server and vice versa. But
even if you know that you
are talking to the right server, you need to trust in the server. The
administrator of the server
has access to all data. Possibly other persons and softwares too.
Passwords are not different from this point of view.
If you're saying that people have no choice but to trust that their
passwords, stored in the clear on the server of some idiot who didn't
know better, are safe from casual administrator observation and safe
from hackers stealing the password file, then you shouldn't be allowed
anywhere near a supposedly secure system...
If you're just saying that one has to trust that the server you are
talking to at this instant in time is really the one you thought it was,
then that's an entirely different issue and I agree.
But storing passwords in the clear, thus allowing administrators full
access to users' passwords, is absolutely *not* necessary. That's my
point, regardless of what other issues this thread spawns. If the OP
implements strictly the sequence he mentioned in the posting to which I
was replying, he'll be the aforementioned idiot...
-Peter If you're saying that people have no choice but to trust that their
passwords, stored in the clear on the server of some idiot who didn't
know better, are safe from casual administrator observation and safe
from hackers stealing the password file, then you shouldn't be allowed
anywhere near a supposedly secure system...
Of course I would not say this. :-)
If you're just saying that one has to trust that the server you are
talking to at this instant in time is really the one you thought it was,
then that's an entirely different issue and I agree.
Not just this.
"one has to trust that the server you are talking to at this instant in
time is really the one you thought it was" - this is just authentication.
I'm saying that even if the authentication is secure and the server is
really the one that you wanted to talk with, the server can still be
vulnerable to other kinds of attacks. Since users are storing data on
the server, they need to trust in its security. Storing the clear
passwords is not a good idea, I agree. But having a secure
authentication method and not storing clear passwords doesn't
automatically mean that the server is secured. :-)
I'm sorry, I was not clear. I think we were talking about the same thing.
Les
dcrespo wrote: then, what you proppose?
I'll assume that question was for me, in response to my comment that one
should never store passwords in the clear.
Do you know how any other system manages to do this? Linux, for example
(assuming a properly configured system)? The passwords aren't stored:
hashes of the passwords are stored (with additional things thrown in to
prevent certain kinds of attacks even if someone nabs the password
(/etc/shadow) file). If you store the password or even encrypt it (i.e.
something that can be reversed if someone knows the key), it's a risk.
If you don't know about this stuff yet, I strongly suggest lots of
additional research and reading prior to implementing a serious system.
There are _many_ web pages to be found which discuss this sort of
thing, probably including lots of tutorials for people starting on the
ground floor.
I bet Paul R or others more experienced in this area can point us to
some excellent ones, but a little googling with "passwords store clear
text" or "encrypted passwords" would get you started. I expect that
would quickly lead to the term "hashing", since you really don't want to
just encrypt the password: that can easily be reversed if anyone has the
key, and certainly an administrator could access the key used by some
random application that encrypts its passwords. The first few hits for
that last search seem to include pages that introduce the concept of
"salt", one of the "additional things" I mentioned above.
I'm not going to try to give a tutorial: I'm not nearly expert enough to
be trusted for that. :-) I just wanted to warn against one of the most
basic and easily avoidable problems.
-Peter
Ok, I understand... What about the MD5? Is it good enough to use when
saving a hashed password on the database?
For example:
user_input = raw_input("Type your password: ")
password = md5.md5(user_input).hexdigest()
SavePasswordInDatabase(user,password)
> Do you know how any other system manages to do this? Linux, for example assuming properly configured system)? The passwords aren't stored: hashes of the passwords are stored (with additional things thrown in to prevent certain kinds of attacks even if someone nabs the password (/etc/shadow) file). If you store the password or even encrypt it (i.e. something that can be reversed if someone knows the key), it's a risk.
Ok, I understand it. What about the MD5? Is it good enough to use when
saving a hashed password on the database?
For example:
user_input = raw_input("Type your password: ")
password = md5.md5(user_input).hexdigest()
SavePasswordInDatabase(user,password)
dcrespo wrote:
Ok, I understand it. What about the MD5? Is it good enough to use when
saving a hashed password on the database?
For example:
user_input = raw_input("Type your password: ")
password = md5.md5(user_input).hexdigest()
SavePasswordInDatabase(user,password)
It would be better to use salted SHA-1.
Ciao, Michael.
"dcrespo" <dc*****@gmail.com> writes: Ok, I understand... What about the MD5? Is it good enough to use when
saving a hashed password on the database?
For example:
user_input = raw_input("Type your password: ")
password = md5.md5(user_input).hexdigest()
SavePasswordInDatabase(user,password)
The usual way to do it is something more like:
import os,binascii
salt = binascii.b2a_base64(os.urandom(6))[:6]
user_input = raw_input("Type your password: ")
password = md5.md5(salt + user_input).hexdigest()
SavePasswordInDatabase(user,salt,password)
The random salt slows down offline dictionary attacks against the
database. Say you have 1000 accounts on your system and the attacker
needs just one password to log in and mess with stuff. With your
scheme, he hashes each word in a large dictionary (say a million
words), sorts on the hash values, sorts your hashed password list on
its hash values, then compares the two sorted lists and if there's
even one match, you're cooked. Each hash he computes can be compared
against all your accounts in parallel. The salt means he has to do
them one by one, slowing him down by a factor of 1000. However,
computers are now fast enough that dictionary attacks against every
single password are a serious threat.
If you have a way of storing a secret key K, then rather than using
unkeyed md5(whatever), use hmac(K, whatever). But revealing K
effectively turns the hmac into an unkeyed hash.
Can you say what your application is? That will help figure out how
far you need to go to protect these passwords, and what alternatives
might be possible.
I highly recommend the book "Security Engineering" by Ross Anderson
for a good cultural introduction to what you're getting into when you
program this stuff. It's a fun book to read, too.
> Can you say what your application is? That will help figure out how far you need to go to protect these passwords, and what alternatives might be possible.
Sure, no problem (see this on fixed text):
___________ MasterServer ___________
// / || | \\ \
ClientServer ClientServer ClientServer
// \\ // \\ // \\
Client Client Client Client Client Client
// = XML-RPC connection
/ = Pure TCP connection
Clients, connects to MasterServer through ClientServer using XML-RPC
ClientServer interacts with MasterServer using 2 modes: XMLRPC and pure
TCP.
Pure TCP connection is used for athenticating ClientServer. When a
ClientServer is authenticated,
the ClientServers can connect to MasterServer for running RPC functions
requested by its Clients.
All ClientServers log in supplying only one hashed password. It is
hashedly stored in MasterServer.
The way I elected to log in is:
-Generate an MD5 string from a Random Alpha_Numeric string on
ClientServer side
-Generate another MD5 string from a Random Alpha_Numeric string on
MasterServer side
-Send each string from one host to the other.
-Apply a Hash algorithm using both MD5 in conjunction with the
password that each one knows.
-Then, the ClientServer sends its resulting hashed string to
MasterServer
-MasterServer then compares its own resulting hashed string with
the one received from ClientServer
ClientServer logs in if:
- IP's ClientServer is not a Blocked IP by MasterServer
- IP's ClientServer is in an Allowed IP Range
- hashed strings match
All this is sustented over a VPN.
Suggestions are welcomed
"dcrespo" <dc*****@gmail.com> writes: Can you say what your application is? That will help figure out
how far you need to go to protect these passwords, and what
alternatives might be possible.
Sure, no problem (see this on fixed text):
Well, I mean, what kind of data is it? Sports chat? Personal
correspondence? Financial info like credit card numbers? Medical
records? Military/diplomatic traffic? I'm asking how severe the
security requirements are.
All ClientServers log in supplying only one hashed password. It is
hashedly stored in MasterServer.
Why do you want to do that? All of them get compromised if the one
password is compromised. What do you mean by "password"? If it's not
something a user has to remember and type in, then I hope you mean a
long random string rather than a password. I sort of remember your
mentioning this though.
All this is sustented over a VPN.
If the VPN is any good, it should authenticate all the peers in some
reasonable way, so why do you need this password stuff at all?
> Well, I mean, what kind of data is it? Sports chat? Personal correspondence? Financial info like credit card numbers? Medical records? Military/diplomatic traffic? I'm asking how severe the security requirements are.
Important data like diplomatic traffic. Must be accessible from all
Clients inmediatly a client publish his data. Its an online system. Why do you want to do that? All of them get compromised if the one password is compromised.
How is it that all of them get compromised?
What do you mean by "password"? If it's not something a user has to remember and type in, then I hope you mean a long random string rather than a password. I sort of remember your mentioning this though.
With 'password' I meant simply a string to log in.
so why do you need this password stuff at all?
I don't want to permit anyone to run RPC functions. It's my desire.
"dcrespo" <dc*****@gmail.com> writes: Important data like diplomatic traffic. Must be accessible from all
Clients inmediatly a client publish his data. Its an online system.
OK, if it's actual diplomatic traffic you need to work with your
government about criteria. If you're in the US, you'd get help from
the NSA. This sounds more like business data. It's pretty normal to
rely on your VPN. That will probably be more secure than some
home-cooked protocol. If it's highly sensitive then you should use
secure terminals (not PC's), hardware crypto tokens at the endpoints,
and so forth. Please do read Ross Anderson's book, it sounds like you
really might need it.
Can I ask what country you are in? Also, how is the data supposed to
get handled at the endpoints? Is it something like text messages that
get displayed on a screen for someone to read? Or something like
database updates? Something like a cash dispenser network where the
leaf clients only make online queries (and maybe dispense cash) but
don't really store much data?
There are a lot of industry standards for different applications like
this. You should follow one if you possibly can, even if you think
your own method is better. There are two problems you have to
consider. The first is how to make the system secure. For that, you
should assume at this point that the people who designed the standards
knew what they were doing. The second is what you'll tell the jury if
something goes wrong despite your best efforts. For that, the best
thing you can tell them is "I followed the standard written by the
industry experts that represents the best knowledge in the field", and
almost the worst thing is "I thought I was smarter than the experts so
I used my own home-cooked method". So in both areas, following
standards is the best policy. Why do you want to do that? All of them get compromised if the
one password is compromised.
How is it that all of them get compromised?
It sounded like you're using the same password on all the clients.
If not, then that helps. so why do you need this password stuff at all?
I don't want to permit anyone to run RPC functions. It's my desire.
I don't understand how the password stuff is related to RPC. You
shouldn't have RPC ports open on the server. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: john brown |
last post by:
I'm using the following code to retrieve a web page. It seems that
I'm able to pass the username and password to the web page, but it
does nothing. Looking at the source code of the web page it...
|
by: Kenshin |
last post by:
Hey!
I have another script where i pull all the information from the database and I want to send it to the person. What they do is they enter in their email, and if the email matches, than it will...
|
by: Lisa Pearlson |
last post by:
Hi,
My php application (on Apache/Linux) needs to do the following:
The PHP script receives a request from a client (binary), asking for certain
records of data.
My PHP script loops through...
|
by: Chris |
last post by:
I have a frontend that has some tables which are linked to a backend.
Now I want to make the backend password protected and when I try to
run it password protected I can't open it. In the first...
|
by: scorpion53061 |
last post by:
is it possible to set the database password that you can set in access for a
database from a vb.net application?
|
by: Jay |
last post by:
error '80040211'
/register.asp, line 71
I receive this error when i attempt to send an email.
My code is as follows:
|
by: oopsbabies |
last post by:
Hello everyone,
I am using Apache 1.3.33 as the web server and PHP version 4.3.10. My
machine is using Windows XP 2002 professional edition which comes with
a Windows firewall. I am using McAfee...
|
by: chaitanya02 |
last post by:
Hi All,
Well- this question might have appeared several times on this forum- but would appreciate your reply on this:
I have a asp page, where customers login with some username and the pwd,...
|
by: Screaming Eagles 101 |
last post by:
Hi,
I looked and found a lot of different code regarding send/receiving
input/output to a command window, but none helped me so far.
I would like to start a process with telnet a bit like this...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
